It works, why fix it?
Posted by Jason Baker on December 30, 2008
It’s such an easy thing to get in the habit of thinking. My code may be written using a platform that’s long outdated, but it works. Why change it? Here’s the problem: your code probably doesn’t work. You just don’t know it yet. Ok, so maybe if you’re working on a 20 year old system using Fortran, you’re close to the point of being bug-free (if that is even possible).
Traversing the slippery slope
But the allure of a software system that works and never has to be touched again seems to draw so many people in. Michael Feathers characterizes these people as Gammas. These are the people that tell you that the website you maintain has gotten along well enough running Classic ASP up until this point. Why consider something else? Besides that, you’ve just got to implement this one feature. After that, the system will work and you’ll never have to mess with it again.
If only it worked that way in practice. The problem is that these kinds of prophecies wind up being self-fulfilling. After all, why should you be very concerned with that one bug report? They told you that you don’t have to worry about the system anymore, right?
Eventually, you wind up with a system that doesn’t work. All those ignored bug reports, those last minute hacks to get it working now, and the general lack of attention paid to the software tend to add up (see Technical Debt). At this point, you’re stuck between a rock and a hard place. Do you take the time to rewrite it from scratch or do you convince your developers to fix a piece of software they didn’t want to be working on in the first place?
Unfortunately, the answer is all too often neither. We’ll just fix it when we get a chance. And that chance never comes.
But my code is perfect! I tested the bejeesus out of it!
Nobody ever says it, but they think it: I’ll do it right the first time. And if anybody does say it, they’re going to be hit with a hard dose of reality soon.
But I’ll humor you. Let’s say that your program is absolutely flawless. Dijkstra himself would be in awe of your programming prowess. And that may even be true for a time. But there’s a thing about business requirements: they have a way of changing in unforseen ways. End users demand more features. Managers change. Laws get passed.
You’d better hope that these things happen sooner than later. Otherwise, the poor soul that gets stuck maintaining your heap of code will hate you and everything that you stand for. And sometimes that poor soul happens to be you.
But technology changes so quickly!
Keeping up with the times is tough. Look, nobody’s saying that you have to be running the latest beta version of .Net version 9.3. But bear in mind that you’re going to have to pay the cost of not keeping up with the pace of technology sometime. And it’s usually better to do it sooner rather than later.