Disclaimer
This article was originally posted by one of the single smartest people in software development known as Uncle Bob on . Sadly his blog seems unreachable and has been for a long time, so I’m reposting the original content in its entirety as a public service. I make no claim I have anything to do with the creation of this article, I’m just preserving it for everybody to read. If you’re not ok with it, please let me know and I’ll take it down. Without further ado, here goes the original article.
The first rule of holes: If you are in one, stop digging.
Many software developers take this to mean that if you have a huge legacy mess in your software you should stop working on it and rewrite it from the ground up.
This is probably the worst thing you could do…
Everyone wants to work in a green field. In a green field you don’t have to deal with the mess that’s accumulated over the years. In a green field you can be clean. In a green field you can build the perfect system. All would be well if only we could start over with a green field.
What a crock. Remember, the original mess started in a green field. All messes started in a green field! The one irrefutable data point we have about green fields is that they frequently lead to horrible messes!
Why do green fields become messes? Because the cows crap all over the place. The grass tastes really good because it’s virgin clean and fresh. And who cares about the occasional cow pie? Besides as long as we walk in the same direction, all the cow pies are behind us and we can’t see them.
OK, I’ve taken the metaphor too far. But the reality of green field projects is that they create the illusion that your messes don’t matter.
Your messes do matter. Every single one of your messes matters. And if you don’t clean them up from the very start, you are going to wind up with a horrible messy legacy wad in short order.
But that’s not what this blog is about. This blog is about what you are supposed to do when you actually have a big ugly legacy wad. So Uncle Bob is going to tell you what to do.
You aren’t going to like it.
When you have a big messy legacy wad, what you have to do is…
You really aren’t going to like this.
What you have to do is… is…
No, sorry, wrong story. What you have to do is stop making the messes and start cleaning them up.
This does not mean you call your managers into a conference room and tell them that you aren’t going to be delivering features for the next three months while you refactor the code. Do NOT do this! Rather, it means that you are going to adopt the “Boy Scout Rule” and check each module in a little cleaner than when you checked it out.
From iteration to iteration, and from release to release, you are going to clean this system while continuing to add new features and functionality to it. There is no other way.
When is a redesign the right strategy?
I’m glad you asked that question. Here’s the answer. Never.
Look, you made the mess1, now clean it up.
I’m not telling you this to punish you for making the mess. I’m telling you this because the green field effort is almost always doomed to fail. Here’s the reason:
Once systems get messy, the people who made the messes start to demand a redesign. Managers don’t want to redesign because they know how expensive it is. But the developers beat the drums of redesign louder and louder. Meanwhile every feature takes longer and longer to add. Bugs accumulate faster than they can be fixed. Bugs that are fixed reappear over and over again. When managers ask why, the developers blame the mess, and beat the drums ever louder… ever louder.
Eventually, out of sheer frustration, management authorizes the redesign. They pick the Tiger Team! The best of the best… The cream of the cream… These are the developers who are going to save the project.
The rest of us hate them because they get to work on a green field while the rest of us are stuck maintaining the old system. And the feature requests and bug fixes continue to pile in.
What does the Tiger Team use for requirements? There may have been a requirements document at one point, but it was never actually accurate, and it’s hopelessly out of date by now! No, the Tiger Team has but one source for requirements. The old system!
But the old system is changing! Those of us not on the Tiger Team are adding new features and bug fixes every day. And that means that we are in a…
Race!
Remember Xeno’s Paradox? Achilles and a tortoise are in a race. The tortoise has a head start. Every time Achilles gets to where the tortoise was, the tortoise has moved to a new point ahead of Achilles. Therefore Achilles can never catch the tortoise.
Fortunately the law of limits allows us to escape this paradox in a mathematical sense. But in software the paradox sill holds. The Tiger Team can never catch up to the old system. Every time they get to where the old system was, the old system has added new features.
I have seen that race go on for ten years.
When (If!) the new system eventually gets to the place where it can replace the old system, all the members of the Tiger Team will be long gone having moved on to other wonderful green field projects. Schedule pressures will have mounted until the new system is finally completed2 through a Herculean effort.And the developers on the new system will have already started beating the drums for a redesign.
I have seen this happen over and over again. Big Redesigns in the Sky almost always fail horribly. Horribly! HORRIBLY!!
Moral
It’s simple really. But you aren’t going to like it. If you have a mess, the only way to get rid of the mess is to clean it. Remember that mess is currently paying your paycheck. That system represents your family jewels. You may have dragged those jewels through the mud, and dipped them in pig dung, but that’s no reason to abandon them for some shiny baubles that look pretty for the moment, but can’t possibly pay your paychecks. Go get the family jewels and clean them. It may take a long time. It may be hard. It may be disgusting work.But in the end you’ll have your family jewels shined and beautiful, and you’ll know how to keep them that way.
1 And if you didn’t, you’ve probably made other equivalent messes and left them behind for others to clean up. What goes around comes around.
2 “Completed” is the wrong word. More likely the system was finally readied through a set of horrible compromises with the product people and customers.Whole feature sets are likely missing, broken, or so different that the customer hates them.
Thanks for reposting this article ! Quick warning about the footnotes links : they still redirect to Uncle Bob’s post on web.archive.org.