I’ve just been bitten. It’s one of the standard strap-lines of software development teaching – do it properly first time, don’t hack it and think you can fix it later. When the deadline is looming however sometimes we have to make a business decision;
- Do we drop the feature (or some other feature)?
- Do we miss the deadline?
- Do we hack it in the full knowledge that we may be bitten later?
Fortunately for us software developers, technical debt is beginning to be understood by business managers. I explain it to non-techies like this;
I could hack it and get the feature in, but if I do that might be storing up problems for the future. Next time we want to add a feature in that area or even fix a bug we might have to unpick the hack and implement it properly before we even start on new work.
Hacking it now is borrowing time from the future – at some point we’ll have to pay it back and we’ll have to pay a wedge of interest too.
A few years ago I spotted a design problem; we’d assumed that something was always related to a location. In some circumstances however it could actually be related to a vehicle.
We should have changed the database to account for this, but that meant changing pretty much every component of an n-tier system and the deadline was busy whizzing past our ears.
There’s no way we could drop the feature so I had to find a solution. What I noticed was that I could cast a vehicle ID safely into a location ID without any possibility of coincidence. We could then detect in the DAL if it was actually a vehicle and generate a fake location record that actually contained all the information we needed.
A few years later and now we’re noticing that customers are putting a whole load more records in the location table than we’d initially thought and the indexing performance of the ID type is poor. So we want to change the type to something that indexes better. None of the options available allow us to cast a vehicle ID to a location ID any more.
Since those early days the problem has been exacerbated by the fact that more and more code has been piled in on the assumption that you can safely cast a vehicle ID to a location ID.
So we’ve now got a considerable amount of code to unpick, we’re going to have to do the redesign and reimplementation work that we (perhaps) should have done in the first place, then we can start looking at improving the index performance.
In situations like this it’s easy to look back and curse the past decision. Go into any software development office and you’ll almost certainly find a developer (or several) swearing at the screen, decrying previous decisions as “stupid”, “short-sighted”, etc.
I know I’ve made mistakes, I know there are situations where I’ve chosen to incur technical debt where there were better alternatives available. On this occasion though I made the right decision – we have time to repay this debt now. Back then we most definitely did not.
So “never hack it” isn’t a rule, it’s a guideline. But you have to be aware of the business consequences if you choose not to follow it.