Just Say No (to the Big Redesign)

In a post Robert Martin made last Friday, he described a pretty common scenario that companies and teams go through in an effort to bring peace and harmony to their codebase and restore order over all their components, known as the big redesign.  Having just gone through this at work and having been on the “Tiger Team” that ported/rewrote our legacy application shell that was a muddled mix of C++/MFC and C#/WinForms, this post really resonated with me.

The moral of Uncle Bob’s story is that the only way to clean up messes in your codebase is to do via incremental changes iteration by iteration and release by release.  If I would have read this post six months ago, I might have argued that this is an overly simplistic take and that exceptional cases exist that make big redesigns necessary.  Having just gone through a big redesign; however, I am confident that fixing your messes iteration by iteration is the only way to fix your codebase issues for the long term especially if your team is trying to develop with agile processes.

My redesign change of heart did not come because of a spectacular failure or the system ending up in a worse shape than before.  I like to think our sob story about how terrible our legacy codebase was made a pretty compelling case for a redesign (doesn’t everyone?) but I’ll spare you the back story.   When it comes down to it, even the best reasons and intentions don’t justify a full blown redesign.  Here is why in big bold letters:

You are not addressing the root causes

A codebase does not fall into disrepair over night.  Having the Tiger Team do all the heavy lifting and making all the design decisions might solve the problem righthissecond but none of the problems that got you in this bind will have been addressed. Also, if the redesign is radical enough, you could actually be reducing your teams ability to manage and maintain your codebase even further.  Choosing to solve your team’s problems by delegating cleanup to a Tiger Team is the software management equivalent of giving a man a fish instead of teaching him how to fish.

Having a big redesign short circuits everything that the agile process tries to address.  If your team is ignoring the feedback it is getting from having to work with brittle code, not delivering on user story commitments, and rising incidents counts, then what is the redesign buying you other than masking these problems for your team a little longer?  If your team is considering doing a big redesign, do yourself a favor and address the real problems your team has.  Just say no to the big redesign.