Mendix and low-code have been around for quite some time now. This means that there are applications that have been created 10+ years ago. Back then, the Mendix platform had a lot less possibilities causing different routes of development then you would choose now.
Applications always build up technical debt and if this is not managed well, the technical debt will pile up. It could be that because of this technical debt you lose speed in your low-code development or even experience applications that have performance problems. Eventually the following question will come up: should we rebuild the application or refactor the existing one?
In this blog I would like to give you some insights in what to keep in mind when making this decision. I acknowledge that every case is different, but taking into account the points below can be a good start in decision making.
Start by making a process flow of the process(es) the application covers, or should cover, and check if your application still supports this functionally in the way you desire. If this is not the case and you have a lot of technical debt, rebuilding might not be such a bad idea. If the current application does cover your desired functionality, looking into refactoring might be the better option.
It is good practice to make a rough estimate of the time needed to build a new application versus the time needed to refactor the application. In a lot of cases, the time to refactor might be lower initially. Mainly because with refactoring we tend to refactor specific parts of the application and not the complete code base. However, please keep in mind that creating a new application could increase development speed in the future. If set up correctly, you won’t be bothered by old, unmaintainable code and will therefore be able to use the speed of the Mendix platform again.
Putting a number on this benefit gain may be difficult, but an open discussion with your development team about this would be helpful. Try and see for example if it will be plausible that the development speed will increase by 50% or 5%. By discussing this you will get an indication of what it could actually be.
In order to make a good decision it could be wise to put a percentage on the amount of functionality that needs to be changed when refactoring. If, in the end, it is just 10% then probably there is no good case to go for a rebuild.
Besides this percentage, it is also wise to look at the current modules within the application. Specifically at how these modules are split. If you find that your application has a couple of delimited modules needing refactoring but the other modules are fine, then it would be good to refactor instead of rebuilding.
When rebuilding an application, you need to think about data migration. With Mendix this can be easily achieved with Excel,JSON export and imports or even database synchronization tools, but it will take extra time. Again the question arises, how much data will this be? And what is the risk of losing data? If there is a lot of data to migrate with a high risk of losing it, maybe rebuilding is not a good idea.
Your application has been used within your organization for quite the years now. What are the plans for the future for the application? If you know the application will only be used for another year, it might not make sense to develop a new application. If you are planning on using the application for at least five more years then you probably have a good business case for rebuilding it. Even though you can’t predict the future, creating a long-term plan is beneficial.
As stated previously, Mendix allows you to split up functionality in separate modules. This gives you the opportunity to create completely new functionality within your old application without having to rebuild the entire application. This is a more pragmatic way that provides you with flexibility while keeping the good things from your old application. Data migration will also be easier since it is within the same database. Don't forget to clean up the old code and keep in mind that there still is a chance you might slow down because of the existence of the old code.
When choosing to rebuild an application or keep the old application and refactor, in both scenarios future development should focus on maintainability. This will ensure that you won’t run into this dilemma again any time soon and it keeps your code base clean.
The ‘Rebuild versus Refactor case’ is one that I have come across many times and it is a hard nut to crack. Keep in mind that every new developer on a project is going to think that they would have done a different or better job. The technical debt that is created most of the time consists of bug fixes, so it is there for a reason. It is knowledge gathered throughout time. Furthermore, if you have a commercial application, like with the Mendix ISV program, creating a completely new application might give away your competitive edge.
If you find yourself facing similar problems, try to analyze and discuss the points above. If at any time you would like to have a coffee and talk about your specific case a bit more, feel free to contact me.
