As part of our software development services in India, we are involved in maintenance and enhancement for software products for our clients. At times, these clients want to explore the option of rewriting the application on some latest technology. Quite often the technical team is also keen on rewriting the application on the latest technology, rather than digging into the existing code base for providing bug fixes or adding new features. While it may be appear to be an attractive option for the development team to sell the idea of development from scratch on the latest technology, there are a few misconceptions and high risks normally associated with the 'rewrite to fix everything' approach:
- Rewriting the code will take less time than fixing the issues: Software development projects nearly always take more time than initially planned. The bigger the project, higher are the chances for it to have cost and time overruns. You may well end up adding many new bugs into the system and having to incur cost of many test and bug fixing cycles before having a product which can be released.
- Existing code base is messy: As the software tends to evolve over time, the existing code base is likely to be messy, and is likely to appear messier to a developer who has not been involved in the initial development. Even with a rewrite, it is very likely that the new code will end up being as messy as your current code by the time development is completed.
- New Architecture and Framework will address all the current issues: It is not easy to define an architectural framework, which can handle all changes and enhancements, which may come in the future and still withstand the test of time in terms of maintainability, scalability and performance. What are the chances, that the same or new mistakes will not be made in the new approach and you do not end up facing the same or some more serious problems?
- Cutting Edge Technology: You may start the rewrite on a technology which is seen on the day as cutting edge, but by the time you complete the development it may not longer be seen as the in thing. Also your current code base is very likely on a well established technology with a wide support base, which is not likely to be the case with the so called cool and latest technology.
Some other high risks associated with the rewrite approach are:
- High Risk of failure - There is a high risk after starting the rewrite you run into serious issues which lead to abandoning the project. This is more harmful in the scenario when your existing product with a customer base has been neglected over this time period as you have moved resources for the new development.
- Missing existing features and workflows - While rewriting the code there is a high risk that you will miss some features and workflows of the existing product. You can be sure it is this feature your customer base will miss the most after release.
The most important reason for your product to exist and have a wide customer base is because it solves a customer problem and makes their life easier. This should always be kept in mind while defining the development roadmap for your product. Any decisions of change in technology or platform should be made with this goal in mind.
The best approach for any technology migration for your product should be planned in a gradual and iterative manner. Some key points which should be part of your strategy are:
- Re-factor the existing code base. Take up parts of the existing code base to re-factor, add useful comments, test and release.
The key word here is Re-factor. This is the least risky option.
- Identify modules or components which can to rewritten and migrated to a new technology with the least effort and risk. This will give you insight on the technology and also validate your approach.
- Develop the core parts of your product on the new technology as a parallel development without affecting the support and evolution for the existing product.
- Your customers may want some new features on your existing product. It is a good idea to release this on the existing product and get valuable customer feedback rather than promising the customer and keep them waiting for the release of the new version.
- Be aware of the end-of-life announcements regarding the technology you are currently using. Plan the migration to a new technology based on this timeline so that you are not rushed into it.
If you take up the porting of your product to a new technology with the above approach and take steps to mitigate the risks, while ensuring that the support to the existing customer and their needs are not compromised, you are more likely to succeed.
Comments