Imagine this: You're busy at your desk, when you overhear a colleague say, "This legacy code is really messy." Someone else says, "Yeah, it's impossible to work with." Within minutes, the entire team has agreed that they're not going to put up with this shoddy system anymore and that someone should do something about it. Someone says the team should be allowed to rewrite the system from scratch to "get it right this time." The others agree and return to work, the mutiny apparently forgotten. You sigh and say to your colleagues, "I understand where you're coming from, but to really fix this problem let's make sure we have a solution that we can sell to our bosses and they can sell to our customers." Your colleagues' jaws drop at the suggestion that they do something rather than just moan. "I don't like the idea of selling anything to anyone," one says, to which another responds, "And our bosses will just say no anyway." "OK," you say. "Instead of selling our idea, how about if we polish it so we don't have to sell it?" They look around, nodding, and then someone asks, "How do we do that?"
The first step is to use the "Five Why" technique to ensure you tackle the right problem. When you ask your colleagues why they want to rewrite the core system, they might find it easy to come up with a list of symptoms, such as "It's hard to work with," "It's flaky," or "It's bug ridden." But there's no point tackling the symptoms—you need to identify the root cause of those symptoms. Keep asking "why" until you come up with what everyone agrees is the root cause.
When I'm trying to find a problem's root, a whiteboard and sticky notes are very helpful. They allow me to present the symptoms (on sticky notes) and the answers to the "whys" (on more sticky notes). Each answer is reviewed until we come up with a root cause.
Imagine that our colleagues came up with the root cause being "Over the years we've compromised the system design such that it has become very difficult to work with."
What do you do once you've found the root cause? The second step is to develop a sensible way of tackling the root cause. In this case, your team has suggested rewriting the system. I call this the "alpha" solution because it still has a number of bugs that need to be ironed out; otherwise, you probably already would have implemented the solution.
The third step is to ask "why" again, but this is a different type of inquiry. Whereas the Five Why technique looks at the causes of the problem (why the symptoms exist), now you want to discover the positive consequences of implementing the alpha solution. After some discussion, your team agrees that rewriting the legacy code will improve productivity and make their jobs more satisfying. But then someone says, "This is so obvious, it's a wonder no one has suggested it before," which brings you nicely to...
Now you ask, "Why not?" or "What are the negative consequences of doing this?" You ask, "What would customers think about this idea?" Most say that in the long run they'd approve, but one person says, "We wouldn't be able to deliver any new functionality to customers while doing the rewrite, which would take a long time."
"And I'm not convinced we'd ever be able to successfully rewrite the system and maintain our credibility," you add, feeling awful about playing devil's advocate.