The rewrite syndrome

It’s not unusual to hear the phrase “stop, we need to rewrite this” at some point in a project. There are even entire projects dedicated to rewrite a system.

Chris Stevenson and Andy Polls told their experience of An Agile Approach to a Legacy System, where they told that

    There had been several previous initiatives to improve the system. The mostrecent was an attempt to rewrite a key part of the system in a language that we knew (Java) on the assumption that this would increase understanding of thesystem and make it more amenable to refactoring.

    This strategy did not work.

Right after this introduction, they provide their two most valuable rules of thumb:

  • Don’t reproduce legacy code.
  • Always ask the user what the problem is.

Marty Cagan, from SVPG, has a very interesting article on this topic named Engineering Wants to Rewrite!, where he says that if a company is not yet at the “stop, we need to rewrite” phase, you can avoid getting there by:

    … [allocating] a percentage of your engineering capacity to what at eBay we called “headroom”. The idea is to avoid slamming your head into ceilings. You do this by creating room – headroom – room for growth in the user base, growth in transactions, growth in functionality.

However, there are some times where the rewrite claim is only a way to draw attention to a project. A rewrite project normally seems to be more important than adding incremental functionalities or fixing one small system piece. However, adding one feature at a time brings value to the customer much faster than the rewrite project. In order to bring more attention to your project, consider using release planning. I’ll talk more about release planning in a future post.

So my recommendation is, prior to using the rewrite word, check the motivation to use it:

  • Did you reach the ceiling and cannot add any new feature to your product? Consider adding the headroom concept in your development team. If you didn’t reach the ceiling, that’s a good way to prevent this.
  • Did all the people that originally wrote the code disband? Consider Stevenson and Pols’ agile approach and their rule of thumbs, “Don’t reproduce legacy code” and “Always ask the users what the problem is”.
  • Do you need more attention to your product, so you come up with a rewrite project? Consider not using this approach. Instead, think about product releases that include bug fixes, improvements and new functionalities.

A rewrite project usually implies in a no-new-features period and some sorry-for-the-inconvinience situations during the project. So whenever you are presented with a rewrite project, analyze its impact in customer value. If there’s no customer value impact probably the rewrite is not the best solution.

Leave a Reply

Your email address will not be published. Required fields are marked *