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
This strategy did not work.
Right after this introduction, they provide their two most valuable rules of thumb:
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:
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:
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.