Practical experience of code refactoring and those pits

In the winter of 2012, I was engaged in software development in a small team of a startup company. At that time we had a real enterprise customer and the first version of the software had been released. The development was completed on schedule, and I was ecstatic and proud when it was released, and it was so satisfying to watch the system serve millions of unique users every day and send out tens of millions of text messages. By the following summer, the company had real revenue, my position had become head of development, the company had hired some new people, and was just about to thrive, and all was well. Then we made a huge decision blunder: we decided to rewrite the software -- from scratch.

Why do we feel the need to rewrite software from scratch?

When we first wrote system code, we had a tight schedule and had to race against time to meet the schedule. So neither the design discussion nor the review meeting took too long - we didn't have time to waste on that - just rushing through a feature, quickly testing it, and rushing to the next. We share office space with other companies, and I remember software development at other companies spending a long time doing design, discussing architecture, and then spending weeks discussing design models.

In addition to the hasty design, the original system is not badly written, and the overall architecture is not bad. Some of the spaghetti code was left over from the company’s previous proof-of-concept, and we didn’t touch it at the time because the code was usable and the construction schedule was tight. But then we decided to rewrite the code from scratch without thinking about performing optimization improvements: the

old code was terrible and hard to maintain;
the "single monolithic java architecture" was not good for our future development and could not support 6,000 10,000 mobile users and large operators with multi-site deployments;
I want to try cool new technologies like Apache Cassandra, virtualization, binary protocols, SOA, and more.
The result was unfortunate: we persuaded the entire company, as well as the board, to get our wish.

Code Rewrite Tour

The official development time started in the spring of 2012, and we set the end of January 2013 as the release time. We needed more people because of the size of the program, so we hired consultants and a few remote developers in India. However, we did not fully anticipate the parallel workload of maintaining the original system, doing new development work, and understanding customer needs.

Remember what I said at the beginning of the article, do we have a real customer? This customer is one of the largest mobile operators in South America. After the system we developed went live, they started asking for changes and new features, so we had to keep updating the original system. However, since this system will be obsolete, we are always a little perfunctory when updating, and try our best to find excuses to reject many customer requests for new features. As a result, the construction period was delayed and the progress was not completed on the original deadline. In fact, our progress was delayed by a full 8 months.

But let's talk about the results first: when the project was finally completed, the new system looked great and met all the requirements. We did a load test and the results showed that the new system can easily support over 100 million users, the configuration is centralized, and the UI tools for viewing charts are beautiful, it is time to scrap the old system and replace it with a new one...

but the customer refused to upgrade request: The original system has gained widespread adoption, their users have come to rely on the old system, and they don't want to take the risk at all. Long story short, we had little success after wasting months. The project was officially declared a failure.

When You Need to Rewrite Code

Joel Spolsky is vehemently against rewriting code, and he advises everyone not to. But I don't particularly agree: sometimes incremental optimizations and refactorings are very difficult, and the only way to read the code is to rewrite it. Also software developers love to write code, to create new things - reading code written by others, trying to understand their code and "mind abstraction" can be boring. However, good programmers are also good maintainers.

If you want to rewrite code, do it for the right reasons and with the right plan. For example,

sometimes old code still needs to be maintained long after a new version is released. Maintaining two versions of the code requires a lot of work. Before starting the rewrite, please evaluate the time and resources required according to the size of the project.

Think about other missed opportunities and compare the priorities of tasks.

Rewriting a large system is more risky than a small system, consider whether you can rewrite it incrementally. We did several things at the same time: switch to a new database, use an "SOA" architecture, and switch to a binary protocol that could have been done incrementally.

Consider developer bias. When a developer wants to learn a new technology or a new language, they will want to use these to rewrite some code. I'm not against it though, it's a sign of a good environment and culture, but it should be compared to risk and opportunity.

Michael Meadows has a good idea of ​​when a "big" rewrite is necessary: ​​components are

technically

so coupled that it's impossible to make changes to one component alone. Redesigning a single component can lead to a cascade of changes that not only affect adjacent components, but even indirectly affect all components. The
technology
Performing a complete rewrite is necessary for this reason, and a gradual redesign has no advantage in this case.
​Redesigning
a single component would result in a rewrite of that component anyway, with nowhere in the existing design to insert new functionality. There is no advantage to a gradual redesign in this case. ​Policy
​ sponsors fail to understand that a gradual redesign requires a long-term commitment to the project. Inevitably: most companies have no interest in continuing to spend their budgets on incremental redesigns. This phenomenon is also hard to avoid when completely rewriting the code, but sponsors prefer to keep investing because they don't want to use half-finished new systems and partially outdated old systems. ​




System users are more accustomed to using the "as-is": in this case, modifying important parts of the system (front-end) is not allowed by policy. But if completely rewritten from scratch, it will bypass this problem. Users will still stick with the "same interface", but this time you've got more reason to fight back. Remember: the total cost of a gradual redesign is always higher than a complete code rewrite, but generally has less impact on the business. In my opinion, if there is a good reason for the rewrite and the company has super good developers, then go for it.
​Abandoning
a project under development is dangerous: wastes a lot of time and money reimplementing existing features, while also passing up opportunities to implement new features, potentially irritating customers and delaying work schedules. If you're rewriting code, that's your authority, but make sure you're doing it for the right reasons, knowing the risks and planning for it. (Source: Sun Wei)