--- wordpress_id: 78 layout: post title: Just Say No (to the Big Redesign) tags: - development - refactoring - programming

wordpress_url: http://blog.kevfoo.com/index.php/2009/01/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.