Computer programming is such a young discipline that it is still very fast moving. New techniques and practices are being discovered regularly. (Unfortunately, also because of the rapid progress, many techniques and practices are lost in the rush and have to be rediscovered on a regular basis.) So many good things. Procedural, object and functional programming paradigms, virtual machines, bytecode, virtualization, concurrency oriented programming, grid programming, containerization and web services (micro or otherwise).

All of these things are wonderful and the certainty of more to come doesn't hurt, but in the thrill of the chase for new technologies, I fear that we have lost sight of a common-sense principle: that is that working code trumps everything.

I've been a computer programmer for a while now (I got my first computer 40 years ago), I love to write code and I love to re-write old code, but I have learned that there is enough work to go around, without the gratuitous re-writing of old code. If it works, and usually it does, if we can be honest with ourselves, then we should leave it well enough alone.

I realise that this is close to the old adage about "don't fix what isn't broken", yet I feel that it's sufficiently different to deserve specifying individually. I'm not saying that we should ignore bad or faulty code, just because it mostly works. Any measurable error rate in code means that it doesn't work to my satisfaction. I'm talking mostly about legacy code, often written in COBOL and running on a mainframe, although while it boggles my mind, even old Java code can be considered legacy. We tend to look at older systems and insist that they should be re-written in insert name of trendy programming language here. This is the time to remember that working code trumps everything. I don't care how buzzword compliant your latest language is. If I have working, proven, code running, then I say leave it alone. Figure out new and interesting ways to interface to it if you have to. Even better would be to just get on with writing some of the boatload of other systems that people are asking us for.

It seems to be a truth, universally accepted, that the armies of the world run on their sergeants and the navies on their chiefs. These non-commissioned officers provide a valuable, nay essential, link between those who do and those who tell. (They also try to keep the new lieutenants alive and out of trouble, but that's a different essay.) It is my opinion that a Technical Lead is like those sergeants and chiefs. They are at the top of the pile of those who do and directly beneath those who tell. And as such they are a key link in the corporate I.T. structure.

Most roles on a project are easy to place in the timeline. Everyone knows that requirements gathering is an upfront activity, that computer programmers work in the middle and that quality assurance testers live on the tail end. A Technical Lead is more difficult to place, because they operate everywhere.

First In, Last Out

The Technical Lead is typically one the first people assigned to a project and usually one of the last to leave it. They are involved in every part of the project lifecycle. When a project is scoped, it will be done by a small team and the Technical Lead will be there, bringing their experience and domain knowledge to ensure that the project attempts to do enough to be useful, but not so much that it will collapse under its own weight. The decided scope then leads to initial estimates. Again the Technical Lead's experience guides by knowing the work to be performed and the capabilities of the team that are envisioned to do the work. Without great care in these important steps, the project will be unlikely to reach its full potential.

I guess I'm just lucky (and you certainly can't rule out the possibility that I'm highly blessed and favored of the Lord), but in over a quarter of a century of professional IT software development, I have been on more successful projects than unsuccessful ones.

Full disclosure demands that I admit that some of those projects were declared successful by management despite a complete lack of evidence of any actual success, but as a humble developer on said projects, we would all get tarred with the success brush, so none of us minded that.

Through conversations with co-workers and using my observational skills, I quickly learned that successful projects are few and far between. I suppose you could argue with my definition of successful project, but that's also part of the problem, that there is no widely accepted definition of what constitutes a successful project. Within corporate IT a successful project is generally one that is declared a success by management. When this happens a party is scheduled, everyone gets cake and coffee and if there's anything left in the budget the developers get a t-shirt or a hat.

I have been internally processing this for a while now, with many pieces falling into place over the past couple of years. This week I was mowing my yard and listening to the Jocko Podcast when enough of the remaining pieces fell into place that I am tempted to describe it as an epiphany. I previously had a minor epiphany on the use of the SCRUM development methodology, so these things happen to me now and then.

By BBC_Micro.jpeg: Stuart Brady derivative work: Ubcule (talk) - BBC_Micro.jpeg, Public Domain, https://commons.wikimedia.org/w/index.php?curid=11672213

I do not remember after all these years, the circumstances under which I obtained my BBC Micro. This was a good 30 years ago now, but I do remember that I loved it and it saw me ably through the start of my Computer Science degree at the University of Plymouth.

The BBC Micro was not made by the BBC, rather it was made for them by a British company called Acorn Computers and the model used was the Proton. The BBC Micro was part of an ambitious project to teach computer literacy, especially in schools.

Image from Wikipedia page for ZX Spectrum By Bill Bertram - Own work, CC BY-SA 2.5, https://commons.wikimedia.org/w/index.php?curid=170050

I wrote about my first computer last month and it seemed time that I wrote about computer number two. This computer was made by the same company as the first, Sinclair Research. The computer was introduced with a cost of £175 for the 48K memory version, which was much more than was available in the family budget at that time. I had a hard time convincing my parents to get me this computer. In my favor was the fact that I had diligently studied programming (not just playing computer games) on the ZX81 and found a friend who was willing to buy my ZX81 from me.

When the ZX Spectrum (or Speccie as it was known to its devotees) arrived, it seemed magical to not run out of memory when writing simple programs. 48K of built-in memory beats a wobbly 16K RAM Pack any day of the week. I think that it's safe to say that I've never run out of memory since that day. Oh sure, I've had operating systems run out of memory (looking at you early versions of Microsoft Windows), but never for a program that I was writing. Also, it seemed magical to have colors (being in England, they were colours of course) on the screen after the monochromatic world of the ZX81.