Whenever a new version of an application is released in your company, are you getting stung by new bugs? Do you feel like opening a beehive when making major changes to your applications? You are not alone. This is the perfect time to modernize your application.

Imagine the application to be an old house. There is a limit to renovation and change. The fact most of us don’t realize is that most of the renovations actually weaken the house structure. The same happens to applications. We don’t realize it because it is virtual. When that life is over for an application there is no use in keeping it on life support. It is time for the application to be born again. Here are some of the things done to the application that weakens it.

  • Inconsistent implementation – When multiple developers work on a single app there is a high probability that the same requirement be implemented in different ways in the application. This increases the cost to fix the bugs in multiple places.
  • Undocumented reuse – Developers sometime reuse a function written for a different area of the application without documenting it anywhere. This increases the chance to introduce bugs when that function is changed because its primary purpose is changed.
  • Bandage bug fixes – The real intention of the Bandage bug fixes is not to fix the bug but to cover its impact. For example developers will introduce a nested try…catch block to prevent that bug from affecting rest of the code in the function.
  • Multiple versions of same component – Sometimes developers tend to add multiple versions of same component. The newer version of the component must have retired some methods which the legacy app still uses so the developers use some methods from old version and some from new version of the component.
  • Missing Big Picture – Sometimes another application that provides input or communicates with your application might have undergone a change and it was not notified to your team. In some cases other dependent applications are migrated to newer version of a platform and the old application is not able to handle the load or not efficient when compared to modernized applications.

If you are an IT service provider undertaking such application to rewrite in new platform then the following might be a good checklist or guide.

  • Requirements gathering – Don’t collect the requirements from the legacy application. I have seen teams doing white-box testing and black-box testing to collect and validate the requirements from the legacy application. The problem is that even the clients are not aware of the full functionality of the application and they assume that lot of requirements which are mostly special cases are implemented in the application. It is better to conduct a fresh requirement gathering session to collect requirements from the user.
  • List the bugs – Document the bugs in the current application and get it signed off from the client. This is the most important risk minimizing phase. Some of the bugs need not be fixed in the newer version of the application because the requirements for that feature might have changed altogether or the feature needs to be retired.
  • List new features – During the rewrite of legacy applications clients will add new features for the new application. Document the new features with complete details. This will help justify the difference is cost compared to developing legacy application. This may be the key to winning bid.
  • Identify reusable artifacts in legacy app – Over the years I have seen that legacy apps have quite a good amount of reusable components or code snippets that can be ported to newer version easily. On the database side I have noticed that the schema sometimes does not change that much and the new database is just a normalized version of the legacy database.
  • Collect documents about legacy app – Some clients have a good amount of documentation about legacy app. Collect those documents and use them in your project. If the client has a dedicated QA team then collect the test plans of the legacy application. This will help you save time on writing test cases by reusing old test cases wherever applicable.
  • Compatibility testing – Before coding check if the third party components used by the legacy application will work on the newer version of the framework or does it support latest design patterns. I have faced some situations where the third party components used in legacy application have to be removed and a totally new component has to be substituted. When looking for new component look for both proprietary and FOSS (free and open source software) and get client’s decision on which one to use.
  • Start with database – If the rewrite has changes to database start with that first. I have seen that some data in database is encrypted and developers didn’t know it until they looked at the real data. Migrating encrypted data is a challenge so handle that first.
  • Code Bottom to Top – Code each layer of the application from bottom most layer. The bottom most layer for most applications is a data access layer. This is implemented mostly using ORM frameworks like Hibernate, Entity Framework etc. I have seen developers starting with presentation layer and then moving on the layers below that. This has always resulted in high amount of rework in all layers. If you start from bottom most layer and move to presentation layer the rework will be minimal. The reason is that your presentation layer works on the data not the other way round.
  • Automate Unit Testing – While legacy application and its architecture may not provide options to automate testing, newer version with popular design patterns like MVC, MVVM provide option for automating unit testing. This automation will save lot of time during QA regression cycles. Use other automation framework like Coded UI, Watin, Selenium, QTP etc.

The top concern that most of the clients had about modernizing their application is about the time it takes to develop the new version from the scratch. They felt that it would take the same time that it took to develop the initial version. While this was true for very few projects I have undertaken, most of the projects I undertook for modernizing took actually lesser time to develop and test compared to the initial version.

Here is how we did it for most of the clients. We met with the clients to go over the current version and found out the features implemented in the application. We also listed the bugs in the current application. We prepared a separate list of new features.  Finally we also listed the reusable artifacts or knowledge from the current version. This phase took a much shorter time compared to the projects that were newly developed. The key factor for success in most of the projects of this type is understanding the processes that the client wants to automate.

New version of any technology mostly provides one blatant benefit which is reduction in number of lines of code to implement a requirement. Use of open source artifacts in the project is another factor that saves time. Finally the new version of technologies support more design patterns than the old ones which helps us simplify lot of implementation details and also provide a valuable option to design the architecture of the application to be more flexible and open to changes and also provides more options to test the applications by automated test methods.

Good luck with these tips.