Do you know how does hell look like for a team of developers? Like millions of code lines for refactoring. If you want a developer to suffer, just make him refactor a complex project. Sanity loss is guaranteed.
Code refactoring is a long and difficult process. So long, and so difficult, that some developers turn their back on the ready project and start everything from scratch – just to end up where they started, with million lines of the bad code. If a project is infected with serious technical debt, software refactoring is essential, no matter how painful it is.
Why do code refactoring?
Development is a creative process. It gets even more creative if you know the standards of software development and follow them. These are not limitations but ground rules, like laws of physics. Standards just have to be followed or everything turns into chaos. By refactoring, you identify pieces of code that don’t correspond with fundamental rules and make them better.
Why not restart everything from scratch?
It’s a big temptation. Starting from the white page, using brand new tools and fancy frameworks, adding cool features — you plan to do it all in a new version. So, the team spent time and efforts just to make matters worse. Existing software debt somehow managed to migrate from the old project to the new one, and on top of that, new bugs appear.
Why follow refactoring rules instead of rewriting?
- You fight consequences, not reasons of debt. Why did the debt appear in the first place? If you don’t know the answer, TD will show up again. It always happens, no exceptions.
- Data leakage. Working on the first version, the development team collected a bunch of data. Now, it has to migrate to the new project and it gets infected, stolen, or lost in the process. It all ends up with a big loss of resources and information, putting the company at enormous risk.
- Company and developers fight a battle on two fronts. While developers work on the new project, the old one yet works and needs to be improved and supported. Therefore, it leaves no possibility to concentrate all the resources on one product.
Restarting seems easy. It is not. Before throwing the old product away, make sure there is no way to improve it. Sometimes there is no way. Like with an Uber case, when they create a new rider app from scratch instead of fixing an old one. With the first app launched in 2009, when technologies were considerably less developed, it was difficult for developers to make a revolutionary app. Or, as Uber says themselves: ‘Not being held back by our extensive codebase and previous design choices gave us the freedom where we otherwise would have made compromises’.
However, for SMEs and young startups, this approach is most often not cost-efficient. While hot-shot unicorns can go for freedom, for most companies it’s way more reasonable to improve the existing product, not spending twice as much on a brand new one.
When to use refactoring in software engineering?
Refactoring is the most efficient way of fighting technical debt in Scrum and Agile. It is worth being considered when there are shortcut quick-fix solutions which perform their functions well at the beginning but stop working when the architecture is more complex.
We have written an essential guide to managing tech debt and conquering refactoring. Take a look.
When to refactor:
- If you have maintenance problems. When the code is written badly, it’s difficult to improve and support. Make it better.
- When there are inconsistent functions. If the same component behaves differently in different scenarios, it should be fixed. Unpredictability is the worst software’s enemy. Find, define tech debt, and fight it.
- If there is code duplication. The duplicated code takes a lot of memory and slows down the functionality.
- If the product functions are based entirely on business logic, it complicates interface. By saying ‘business logic’ we mean not business objectives or rules, but the architecture based on illogical boundaries and unnecessary variables. Not only it burdens an application but it also sits between good smooth functionality and intuitive user interface.
We covered what and when to refactor. Keep in mind that refactoring both in Agile and Scrum is the long and resource-consuming process. Therefore, it has to be justified by business interests.
There are cases when refactoring is just unreasonable:
- It’s a short-term project (like a small app for the Christmas sale)
- When you feel the previous version of the project also lacks technology disruption, and you have the goal of bringing innovation to the market.
- If the cost you’ll receive from the project is less than the resources you’ll spend on refactoring
- If you lack resources for testing and debugging.
However, if your marketing strategy is based on a technology solution, it has to be perfect. That’s why tech-driven companies like Microsoft, invest a lot in retargeting and constantly improve their products.
If you have a project that you’d like to improve, we are happy to assist. Our award-winning team of testers and developers with 17+ years of performing projects for SMEs and big corporations like Skype and HuffPost will look into your product, assess it, and bring it to the highest standards of modern technology. Just contact us!