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.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products