This post by Robert Martin describes a pretty common scenario that companies and teams go through: The Big Redesign(tm). The gist of Uncle Bob’s story was that the only way to clean up a codebase is incrementally. Piece by piece, iteration by iteration, release by release. If I would have read this post six months ago, I might have argued that this is an overly simplistic take. Surely there are situations where a big redesign is not only necessary but the prudent option. However, having just gone through this at work, I’m more than convinced that he is right.
My redesign change of heart did not stem from a spectacular failure or the system ending up in worse shape. I’d like to think the state of our legacy codebase made a compelling case for a redesign (doesn’t everyone?) but rarely is the design itself the problem. It is the conditions that allowed your designs to become unmanagable or problematic.
A codebase does not fall into disrepair over night. The state of the system is the sum of all the decisions and the environment applied to the system over its life. Calling in a “Tiger Team” or your best engineers to execute a grand redesign might provide relief righthissecond but that relief is usually fleeting. None of the problems that got you in this bind will have been addressed. Trying to provide a fix without improving the processes or decisions will only lead to another mess.
The big redesign might be sexy and alluring but it is rarely the right decision.