Maintenance suicide: the short-term fix myth

How many software features have you seen added on like this:

This is a great example of a short term fix... a bunch of bungee cords, a ladder, and a pair of vice grips to hold a red rag on the end. If you're moving a single piece of wood its no big deal, but I have seen far too many features or even whole applications cabled together like this.

Immediate needs require a quick solution... but in software development time is almost never allocated to clean up the mess afterward. That's the myth, that short term solutions in Software Engineering are ever short term. In reality they're left in place until they start to fail or can't meet current requirements. After all, a working feature will never rank as high as the next fire that crosses your bosses desk (and at organizations that regularly do things like this, there is always another fire waiting).

It's maintenance suicide. Short term solutions never hold up to long term use and changing requirements and they are nearly impossible to maintain. Lets take our current metaphor further... what happens when the business comes back and says now they need to move 200 pieces of wood at a time or that they need to be able to open the trunk while moving wood? Clearly the current solution won't work and we'll likely have to start from scratch.

And that's just what happens at short term minded organizations... there is never time to do it right, but there's always time fix it when it breaks or to just to do it over. A few years ago I was at an organization that ground to a halt after 6 years of short-term, business driven decisions. The short term fixes were breaking right and left under the weight of the growing business. Short term solutions are the antithesis of long term stability in a company.


Post a Comment