I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
Haunted legacy: a Halloween code story
It was 17:55 on the 31st October. Five minutes before the programmer’s shift ended and the night shift took over. The time when you hope that no new bugs will be reported and no new tickets will be raised.
Ping!
The ticketing system sounded an alert, and the notification bubble popped back into existence, a bright little ‘1’ in the middle of its red circle.
A moment in the project plan; a lifetime in the codebase
Software can be a source of regret as well as value. It is a common experience to find yourself looking at code and wondering what fool could possibly have written it, only to read the comments and find out that it was you.
The passage from choice to regret is often clear to developers, despite their faulty memories. You knew what you were doing when you made those decisions – and that you (or someone else) would pay for them in the future.
However, this path is not so clear to other stakeholders and non-technical decision makers – and their choices are often the ones that create the most regret.
I was going to do something about legacy technology but I forgot . . .
Have you ever had the weird experience of reading a book and, part way through, realising that you’ve read it before?
Or being recommended a book, going to buy it, and realise that it’s already on your e-reader, marked as read?
Human memory is strange and fallible. It seems that it is possible for us to spend hours engrossed in an activity which occupies our minds, and then completely forget about it.
The time to care about code quality is now
What do we talk about when we talk about legacy technology?
Sometimes we talk about infrastructure: hardware that is out of support, operating systems which have not been patched or tools which are out of date. And sometimes we talk about commercial software: packages that have not been updated in years, products which are no longer made, and vendors which have gone out of business.
These forms of legacy can dominate our talk, as they present the most immediate and obvious threats: the unpatched server that is a beacon for attackers, the ancient hardware that may never turn back on again if we lose power, and the support line that just rings and rings.
Thinking differently about . . . the persistence of code
This week I learnt that some of the code I wrote thirty years ago is still running in production. I don’t know whether to be pleased or terrified, but I know that it’s not the first time I’ve had that surprise.
Back at the beginning of my career, I wrote part of a system using technologies which barely exist in memory today: Application Master on an ICL mainframe accessing an IDMSX database. Ten years later, I did some more work for the same company, and was surprised when the year 2000 project team (yes, this was around 1999) approached me, asking me whether I knew anything about this code with my name on it. I recognised the code, but had never imagined it would be running ten years in the future.