Here’s an interesting BBC article on the benefit of staying simple when performance really matters, as seen from the high performance perspective of Formula 1 racing driver – and former world champion – Lewis Hamilton.
Hamilton’s central argument is that “When it’s not simple, it can be stressful, and when you’re stressed you’re not working at your best.”
It’s well worth a read.
It’s fashionable these days to talk about “technical debt”. If you need a primer on this, Martin Fowler gives a good concise explanation of Technical Debt.
The concept itself is fair enough: each time you hack something into your software code without doing it properly you store up problems for the future, and these problems are added to your technical debt. In that sense it’s a useful way to think about the problem of how a code base gets polluted and harder to work on as time progresses, as the debt either mounts up or gets tackled and reduced.
So far so good. But when I hear people using the phrase “technical debt”, it’s mostly used as a buzzword. The actual meaning is lost. It’s a euphemism. When they say “There is a lot of technical debt on the project”, senior people nod sagely … and then ignore it.
That’s because “technical debt” doesn’t really sound that bad. It’s the same reason the military say “collateral damage” rather than “slaughtering innocent women and children” – it just tends to sound a bit better!
If you could put an accurate financial value on technical debt, as you can with real financial debt, then maybe a conversation on technical debt would have some meaning. There have been some efforts to quantify technical debt, but you might argue that the methodologies are vague and the final numbers don’t really stand up to scrutiny. Maybe they never could.
So what I really dislike about the phrase “technical debt” is the Euphemism Factor, the way it can pull the wool over the eyes of management, and even people on the project, and make them think that things aren’t as bad as they really are.
Let me put it this way. If you were the boss, and a project manager was reporting to you on their progress, what would you think if they said this: “There’s some technical debt on the project, so it will be quite challenging to add the new features.” That’s a phrase I’ve actually heard someone use. And I saw the boss take it, nod his head, and move on to something else.
What the project manager actually meant was, “This code base is so wrecked we can’t do anything with it! Every time we try to add something new, we break a dozen other things. We’ve built fudge on top of fudge on top of fudge, and the whole thing is about to come crashing down around our ears!”
Let’s face it, what we’re really talking about here is honest conversation. Take a look at some of Jack Welch’s books. (Jack Welch was the CEO of General Electric from 1981 – 2001, and is widely held to have been a highly successful CEO). He often talks about the power of being what he calls “candid”. You might choose to call it honesty, frankness, or being straightforward. Or as Dan Kennedy puts it, “No B.S.”
My recommendation is to move away from euphemisms like “technical debt”, unless you’re attempting to do some kind of serious financial quantification of it, and move towards concrete, specific comments that quantify the problem in terms that are meaningful to the business, and emphasise the potential productivity that is being lost.
So maybe what the project manager should have said was something along the lines of, “Due to the speed with which we’ve had to release new features, and the number of different developers that have worked on the project over the years, the code base has got really difficult to work with now. We’re finding that we break quite a few things when we add new features, so we’re always treading on eggshells, and that slows us down a lot. We haven’t got enough automated test cases to give us confidence that we’re not breaking the old things when we add the new things. So adding this feature is going to take us at least 4 weeks, when if the code base was cleaner we could do it in 2 weeks at the most. The last feature took us 6 weeks, and we think really it should have been 3 weeks, but we broke existing features X, Y and Z in the process, and fixing them took us 3 weeks.”
It takes a bit longer to say, but it shouldn’t take long for the message to sink in!
I’m obviously not suggesting charging in with both boots and telling the CEO in no uncertain terms that we’re all doomed! But what I am suggesting is that you’ll get better results if you move away from vague terms and management speak, like “technical debt”, that can be brushed under the carpet and ignored, and start talking in practical, quantifiable terms about the poor state of your code and how it’s affecting your productivity. Then you might get the chance to do something about it!