A potential client is considering a major rewrite of one of their most important applications. Now, at first I’m seeing a few dollar signs for a new project, but then I come back to earth and start thinking again later that evening. Strangely, my business partner, John, starts an IM conversation with me about software rewrites even though I hadn’t yet told him about the conversation I had with the client.
I hit the net searching for discussion on this topic and found plenty of blogs saying “don’t rewrite, refactor instead.” However, no one really speaks in favor of a rewrite. Here, we list reasons in favor of a rewrite:
- Performance: The existing architecture and code was written in a day when the transaction volume was several orders of magnitude less.
- Turnover: With a twist to the meaning of the term, everyone has heard the stories about this code and has managed to push back on every feature request for years. In that time all of the developers that actually did know that code have left.
- Business has evolved: Similar to the performance reason, the business has evolved to the point that the architecture is challenged to meet the needs.
- Development speed: The code is so rigid that developers cannot deliver features fast enough and the business is unable to take advantage of changing market conditions.
I contend that all of these reasons boil down to just one:
When changing the existing code is more expensive to the business, it is time for a rewrite.
This should absolutely be measurable. Compare the estimated development time of the requested features and the ROI of those features based on time with the estimated development time to rewrite.
I am proposing my client invest in a little time to evaluate the code closer for refactoring options.