Every software system which does not fail soon enough, comes to a point where a team has to face a question how to get out of the complexity nightmare and change the architecture. The goal is to have a maintainable application where adding a new feature does not cause the product owner's headache. Let me tell you why you will fail if you decide to rewrite.
If you have already started this discussion in your team whether rewriting the application makes sense, you have probably already heard arguments like:
- It should be easy, this system does not do much.
- The concept of the application is simple. There is not much of business logic to cover.
- Most of the current features are not needed. Creating a new application from scratch with the basic functionality will be quick.
What is interesting, such statements are spoken even more often by developers that have been longer in the team than the new ones. It all seems fascinating: no technical debt, green field, new technologies. Yes, new technologies.
Technology stack - why not to argue about it?
Once you decide to rewrite, everybody is excited and want to participate in the initiative. You all have technologies of your dreams. Do not be surprised that your colleagues dream about using other frameworks than you. There are so many popular toys for developers that you simply cannot use them all. Now you realize you have to somehow decide on the technology stack. If you have an architect, he/she will make the choice and a part of the team will hate it. If the team can come up with the list, it is not better really. Be prepared for endless discussions. There is also the third option. If you work for a corporation, the team architect does not have enough power to make an autonomous decision. There are also enterprise architects which will not give up on making an impact on the technology stack.
If you have lost some joy of creation, do not worry, you will start coding soon.
Incremental approach? Not possible!
In the mean time, the product owner realizes that you are not going to rewrite the system after work. It will have impact on the current projects. There is nothing surprising in his/her question about the total estimate of the initiative. If you have thought about doing it outside of the company procedures, project plans, management, you were wrong. Although nobody asks you for a detailed estimate, a single number - XYZ mandays is not enough. It must be broken down to features. You give me a list of functionality, we will give you estimates you would want to say. It is even easier, the product owner wants all options of the current application plus a few more. Wait. Did not you want to start from the minimum set of features? Did not you think that some of them are not used and not needed so you could simply forget about them? Yes. But the product owner will be convincing you that all of them are absolutely necessary and building a system with missing some of them is pointless.
Even if you do it incrementally, as you probably do in Agile methodologies, it will not be released to any client until it has all functionality of the old application.
Too high estimate
Finally, you come to terms with implementing all these features. At the end of the day, there are not so many of them, right? You make a list, create epics, high level stories and estimate them. The result may surprise you or not but the product owner will be surprised for sure. The estimate is far bigger than expected.
You told him it is a simple system, you have already implemented it in the old application so doing it one more time but better with new technologies will be faster with no technical debt at the beginning.
Depending on the determination, you may try re-estimation with other group of people and a different split to stories. A total cost will be still far for satisfactory but someone will neglect it explaining that it will not take that long for sure, it is overestimated. And if you are (un)lucky, the implementation will start.
No source of requirements
Wait. Starting the implementation? You estimated empty epics and high level stories. A product owner or a business analyst should write requirements down. A problem is that the current system is very old and nobody knows all use cases that should work. The simplest answer is that the new one should work exactly as the old one but without bugs. Do not expect that someone will create a complete description of features that you could use for implementation.
A way out of the situation is the analysis of the old code. However possible, the old code is mess. That is why you wanted to rewrite it in the first place. You were tired of trying to understand such complex ugly thing. Now you find out that a deep dive into it is inevitable. Arghh ...
Higher priorities
The outside world has not frozen when you started the rewrite. Now, your hands are needed somewhere else urgently. The initiative is put on hold, temporarily. Two weeks later, a half of the team comes back and continues the work for the next two weeks. Then, even they get assigned to a more important project and it becomes clear that nothing much will happen to the rewrite for the next half year.
It is not only you who see the problem so different ideas emerge:
- form a sub-team dedicated to the initiative
- engage external contractors to build the new system
- create a team from the most talented people in the company
I think I do not have to say that none of these solutions work like a charm. Any group of people may get switched to other projects anytime. On the other hand, external contractors have no clue about the old system and as you do not have requirements written down, they will not be able to build a new application that would replace the current one.
Chasing the running rabbit
Trying different approaches you get to a conclusion that the team has to share its time between both: maintenance and the rewrite. You may even agree with stakeholders on a precise percentage of each Scrum sprint for example dedicating at least 50% of the team effort to the project.
Unfortunately, you realize that fixing bugs and adding new features to the old system extends the scope of the new project too. The initial estimate did not include that. It becomes clear that you are not moving faster as you hoped but slower because of the rabbit that is not standing still, it is running away.
New system should be a panacea
If it did not happen earlier, you realize now that people outside of the team believes that the new software will solve all problems of the old one. Hence, bugs in the legacy system are fixed as cheap and ugly as possible because the new one will have it done right.
The same applies to features. The product owner has a huge list of enhancements in his/her mind that were expensive to do in the legacy system. Now, he/she requests them in the new application to be implemented to the first release. One, two or even 10 such extensions would be understandable but you hear much more of them. Nobody is able to define requirements for the basic functionality but 50 extensions are waiting in the queue for implementation.
If you have already survived all these issues and you are still progessing on the rewrite, do not feel save - they tend to come back. They might hit the initiative and stop it at any time!
Remark
This article is not a diary. It does not describe one case I have had. I have participated in a few rewrite initiatives and I have discussed a few more with my friends from the industry. The above text is a part that is common for most of these cases and I believe it is somehow inevitable if you decide to rewrite a legacy system.
Does it mean I am against such initiative? Not necessarily but in most cases when you think let's rewrite the whole system, I would say it is a bad idea.
So what is the alternative? For example a refactoring as it is safer and does not have most of the above problems. It does not mean it is easy, but it is a topic for a different article.