- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
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.
Have we overloaded the term ‘technical debt’?
What do we mean by technical debt?
These days, we seem to mean a lot more than Ward Cunningham did when he first coined the term in 1992. As Cunningham has helpfully clarified, he was specifically referring to coding choices made in the absence of full information - information that could only be gained by releasing a version of the code and learning how it was used. The technical debt incurred in this way could be paid down by refactoring the code as its full feature set became apparent - or could be ignored, at the risk that, just as with financial debt, servicing the debt would become all-consuming: developers would spend all their time navigating an ever more complex code base, full of incrementally added and contradictory concepts.
A tale of two codebases
It was the best the code would ever be; it was the worst the code would ever be.
Let me share two stories about software development.
In the first story, I was working on a software project. For the purposes of this story, it doesn’t really matter which one: after a while, all software projects have similar characteristics. But let’s pick a project in which I was helping build a new billing system for a utility company. The project started well, with a structured approach to architecture and requirements, and it seemed that we had all the time in the world. But, as the project progressed, the time vanished. The list of requirements got longer, not shorter. Programs returned from the testing team with more bugs, not fewer. We replanned, and rescheduled, and rebaselined, but didn’t find any magic ways to create more time. However, we crunched through, and eventually broke into the clear: with a bit of nifty rescoping, and expectation setting, and agreement that we had to release something, we launched the system. We survived the first few months of teething problems, and the system settled down. It wasn’t what had originally been envisaged, and the code was full of compromises and inefficiencies. But it was running - and when it was running well enough, the project was shut down and we walked away, some of us to start the next cycle all over again.
Sometimes it’s fine to have a solution looking for a problem
The lightbulb was not always the symbol of a good idea.
Edison’s incandescent electric lightbulb initially met with scepticism on both sides of the Atlantic. Henry Morton of the Stevens Institute of Technology said that, ‘Everyone acquainted with the subject will recognise it as a conspicuous failure,’ while a British Parliamentary committee said that it was, ‘unworthy of the attention of practical or scientific men.’
Part of the reason for this scepticism was due to problems that had not yet been solved, such as the distribution or ‘subdivision’ of electricity. But part of it was also due to the feeling that these problems did not need to be solved: there were already established ways of providing illumination. Edison’s lightbulb was a solution looking for a problem.
What’s hiding in your technology sock drawer?
If you celebrate Christmas, I hope that you got some good presents. But you may also have got some presents that seem fun for a few weeks, or a few days, or a few hours and that you then put away, never to take out again.
In the fascinating podcast series Gamecraft (https://www.gamecraftpod.com/), Mitch Lasky and Blake Robbins explore the history of the video game industry. I learnt a lot from this series about the economics and history of video games, as well as the way that the behaviour of developers and players has shaped and been shaped by games. I recommend listening to the whole series, but there’s one concept that particularly stuck with me: the idea of ‘sock drawer ware’.
This is consumer technology that appears to be a good idea, and that looks like it will gain a committed, sustained audience, but ends up in the sock drawer after a few weeks. (This term crops up in the episode about virtual reality - sorry VR people, but this seems like a good way to describe the repeated waves of enthusiasm and indifference that have greeted developments in VR. Perhaps this time round it will be different.)
How do we make non-functional requirements exciting?
They’ve got that look again.
If you’re a technology architect, particularly one who designs infrastructure, then you’re used to people getting that look. Their eyes glaze over, their smile becomes fixed. They may have an air of panic. Why is this person talking to me? What’s a server? What is latency, and why are they so worried about it? What’s the quickest way out of this meeting? There’s only one sure way to dispel this look: to start talking about time and money.
Welcome to the conversation about non-functional requirements. This is the time when the technology architect tries to agree with their business sponsor (or, more usually, the business sponsor’s representative) what compromises they will make together. Because there are always compromises: if you ask someone how much downtime they can tolerate, what the response time should be, and how many users the system needs to support, the default (and not unreasonable) answers are likely to be: none, instant, and everybody. Until you explain how much it would cost and how long it would take to achieve those things.
Are we any good at explaining technical debt?
Updating code can sometimes feel like an Indiana Jones movie: avoiding traps, solving puzzles, evading dangers and unravelling mysteries of the past. And, if you get it wrong, frantically trying to deal with the huge boulder of mayhem or swarm of bugs that you have unleashed. What makes it worse is that the people that created these traps and riddles were you and your teammates, and you did it just a couple of months ago: it’s astonishing how fast the memory of code fades.
This is, of course, the world of technical debt. While this is a powerful metaphor, and a term used frequently by technologists, I think that we are often unsuccessful in conveying its importance to non-technologists, especially in large enterprises. If we were more successful, then our systems would be less full of short term fixes and quick bodges, and we would give more funding and resources to refactoring and code repair. The state of our systems shows that we have more work to do.