Application refactoring vs rewrite

Douglas Crockford says that computer programs are the most complex things that humans make and that changing one correct program into a different correct program is extremely challenging.

Besides my programmer ego want’s to believe in him, I’am not sure if he is right on the first part of the statement but I know, by experience, that he is right on the second part. Changing computer programs can get challenging and sometimes even more challenging than creating a brand new program.

Due to this complexity and a somehow volatile environment there is always the day where we get to the crossroad: refactoring or rewriting.

This inevitability haunts programmers and decision makers since the early days of software industry and it is caused by series of factors being the number one the fact of computer programs being done by humans.

Technology evolution also plays an important role on this. In a short period of time we passed from “offline” desktop applications to web applications, mobile apps, progressive web applications and probably in not so long time we will have a generalisation of offline web applications. This is caused by the drop of computer power cost, generalisation of broadband internet and a wide variety of mobile devices.

The problem

There is a great amount of factors that change over the lifetime of an application that makes it evolve, most of the time, on undesired ways. — This is a strictly technical point of view. Not an evaluation of application success.

The technologies and practices change, the amount of developers who work on it will increase over the time and, probably, the business area that the application initially was intended to respond had also changed.

Applications are done by humans who by nature are not perfect and commit errors. During the software development process there are humans on different roles that commit different errors:

• Excessive optimist leads to under estimations of time and cost
• Difficulties evaluating requirements lead to defective systems
• Wrong architecture decisions can affect system overtime
• Bad estimations lead to a tendency to skip patterns and refactor “later”

These (and other) errors lead to the day where the application has become a kind of monster that is hard to handle. The code will contain functions that no one really knows how they work and what side effects they have due to hard coupling of components. Testing is hard and probably there is no automated tests available and there’s always “that part of the code” that no one really want’s to touch.

Changes had become harder to do and most of the time they lead to bugs compromising the evolution of the product.

Does it sound familiar?

Refactoring

The objective of refactoring is to introduce modifications on the code that over the time will improve the overall quality of the code base making it easier to maintain and evolve over the time.

Refactoring allows to improve the application on the fly. One of the advantages is that it’s possible to continue to deliver updates (not just bug fixes) to the users while seriously improving the system code base.

In refactoring It is harder, or most of the times impossible, to change technologies or frameworks. But possibly this can be done after the refactoring roadmap is complete because the code base will be better and based on patterns.

One of the biggest challenges of refactoring is that after doing the modifications the system should work the same way as it did before. For this reason, usually involves an high amount of testing and debugging.

Since refactoring usually doesn’t involve a complete new stack of technologies it’s harder to motivate developers to do it.

Rewriting

One good thing about rewriting is that it’s an opportunity to (re)do everything from scratch. The selection of technologies and paradigms is completely free from any legacy limitations that would probably exist when doing a refactoring.

Everything can be changed. The language, the patterns, the frameworks and even the type of the application: desktop to web, web to mobile, whatever would seem right at the time.

In theory, given the experience acquired over years of developing the first application would prevent the team from repeating the same mistakes. So, no spaghetti code, unit tests will be written and the coding style would be flawless. For these reasons, usually programmers tend to push a complete rewrite over a refactoring.

But, apart from theory, things will also get problematic when doing a rewrite. The human resources need to be distributed between maintenance of legacy application and rewriting a new one which causes a constant change of scope that will affect productivity. This could be fixed by hiring new programmers to work on the rewrite but probably they will lack experience on the business area and that will lead, again, to poor productivity and a poorly designed system.

Also, the transposition of functionality from a system to another is not always as simple as expected. There are dark parts of code without unit tests to be transposed that no one really knows in detail that are hard to transpose and debug.

For these reasons, from a strategic point of view, it’s probably riskier to do a complete rewrite: it will cost time without real evolution on the original system, it will cost money and the final result will come with an higher level of unpredictability because it is harder to inspect the results.

Conclusion

Rewrites are hard and can easily end in disaster. There are some “popular” rewrite failures. Textmate for instance took six years to deliver a beta version of it’s new version and few months later they ran out of business. But I don’t think these failures are reasons to put rewrites apart “no matter what”.

I think it’s strategic decision and that the right option will depend on your application size, user base size and currently state of the code. In a big enterprise application with a large user base probably a refactor would be a better option. The bigger the applications are, the more time will be necessary to do the rewrite and that may compromise the time to market of a new solution.

Also, with a large user base, probably you will want to , other hand, they are happy with it? Because if they are happy, you will probably want to do a refactor to make the maintenance easier and prepare greater future modifications instead of changing lot’s of things around.

So, some bullets on the pros of each one of the options.

Pros for refactoring:

• Strategically it involves less risks because the changes are incremental and it is possible to inspect results (including user feedback) and adapt as necessary
• The amount of time required is shorter than the rewrite
• The development team(s) will still focused in evolving one single product so there is no splits in productivity
• At the end the system will be easier to maintain and product evolution will be faster

On the other hand there are some pros also on rewrite size:

• Allows a complete change on technology stack (sometimes a rewrite can be forced for technology reasons).
• It’s easier to impose best practices
• Probably the team will be more motivated with the perspective of creating a brand new application

I would like to hear your thoughts on this. Leave your comment bellow.