I read an interesting article recently about the idea of “Technical Debt”,
Technical Debt – 10x Software Development
This article raises several issues for me. Firstly it is a sane and readable analysis of a problem that everyone working in the Software Development Industry has faced at some stage or another. The idea that we should track our shortcuts, hacks and the “hey, I just noticed we screwed this up, but there’s no time to fix it” moments with an aim to paying them back is laudable.
Personally, I’ve always had a problem with this part of our industry. No builder of houses would ever say “well, we promised it’d be ready tomorrow, they’ll pull the job if it’s not, so I’ll just wrap it up with duct tape and they’ll never know the difference in the inspection and fix it properly later.”
Actually I can’t actually -know- that this has never been done, it probably has, but I know if word got around that builder would be out of work before he could blink. This, however, is exactly what we do when we get into the “There’s no time, I’ll just hack it up so it works for the demo” frame of mind, and it is not only accepted but seems to have become “Standard Working Practice” for the industry as a whole.
I’ve always felt this to be a betrayal of my integrity and have felt it keenly every time I have been forced to do so. Even moreso by the fact, as everyone knows, that the later fixes Never Happen.
That, in my mind, is the big problem with this article. An awful lot of software developers are working to fixed price contracts, and when the release is delivered with hacky code that is dangerous but satisfies the customer, there is very little incentive to go back and fix it. It’s easy to say that “when things slow down we’ll fix it”, but in the current economic downturn many large software shops have to account for all of their developers time and work. Try explaining to an account that “Yes, it worked, but it wasn’t good enough.” For that matter, try explaining this to a client who wants to know why you want an extra couple of days to work on functionality that, as far as they can tell on the surface, already works fine.
That is the big problem we have as software developers. Whilst people can immediately understand why a building held up with chicken-wire is a bad idea, it’s not so obvious why an application held together with hacky glue code is a bad idea.
It’s also important to note that if you’re unwilling to go to the client and say “We need a few more days/weeks to work on this functionality”, then you’re probably not telling them that the code they’re looking at is hacky either. Odds are good you’re hoping they wont notice and planning to fix it quietly in the background before too many more releases go by. This means that at the end of the release cycle when the project is nearly done and you’ve still not found the time to fix these problems, you’re not going to be able to explain to the client why you need “just a few days or weeks more”. You can’t tell them that you’ve been dishonest, and the functionality they think works fine is only a few coincidences short of crashing and burning horribly.
So you’ll deliver the final version with the hacky code still in it, you’ll console yourself that maybe you’ll have a chance to fix it during the support period though you know it’ll never happen so long as the hacks hold together. In the end the company just holds it’s breath and hopes nothing goes wrong before the warranty period expires.
The techniques in this article might help a bit, by encouraging teams to pay back the instances where such hack work in unavoidable. It also sounds as if it would work far better in cases where an application is being developed in-house, rather than to-contract. I think the industry as a whole though needs to focus more on scaling back just how often these “Technical Debts” are incurred, and understand that the majority of them never get paid back, and the eventual cost may well be to your reputation.