You’ve spent months building your product, getting it to the market, promoting it on social media, gaining your first hundred paying users. You are already planning the new killer feature, when the development team sends you and email about… refactoring? Seriously?
Don’t be so quick to reject them. Refactoring is often misunderstood and undervalued. But if you approach it wisely, it will definitely pay off.
We at Belitsoft deal with similar situations almost monthly, being a software development vendor. In this article we will explain the concept of refactoring, how to see whether your project needs it, and give advice on how to handle it best.
What is refactoring?
Contrary to the widespread opinion, refactoring has nothing to do with rewriting poor-quality code. A professional software development company will always deliver solid work. Moreover, they will cover it with tests and use the modern microservices architecture to improve the overall quality of the application.
Now that we’ve got that out of the way, here’s how refactoring was defined by the authors of the defining work on the subject:
“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior,” M. Fowler, K. Beck et al.
Simply put, refactoring means making small changes which don’t affect how the code works but make it more understandable and clean. As a beneficial side effect, optimization might increase your app’s performance.
Scalability — this is the aspect that refactoring improves the most. If a software product is growing it has to streamline its codebase. Otherwise adding new features and optimizing it for new users will become a long, slow and costly process.
Refactoring is similar to brushing teeth. While it requires some time and money, the costs are negligible compared to benefits. And it is a prophylactic work that should be ongoing if you want to avoid the exorbitant costs when the emergency happens. We don’t question whether we need to brush our teeth, so why treat our projects differently?
Why can’t you write clean code within the current budget and timeline?
There are three main reasons.
- Unclear requirements. In the beginning, neither the product owner nor the developers can predict how their software will evolve over time. The team works as well as they can in the information vacuum, but they can’t prepare their code for everything. Thorough business analysis and writing a detailed Requirements Document could take months or even years. Only a few clients have this much time.
- Time constraints. A startup team needs to release their product quickly to test it in the real world and start receiving user feedback. The success is far from certain, so spending time and money on the perfect code is pointless. The fast solution is more valuable than flawless one.
- Different experience and coding styles. The project team is usually composed of developers with varying levels of experience. It is a sound decision from a financial point of view — simple tasks should be done by less expensive junior developers, while the senior programmers focus on the more complex issues. Moreover, different coders implement features differently. This creates inconsistency which also makes the code harder to read.
All those reasons create the so-called “technical debt.” Left unchecked it will drag your product down and cost you money.
Prudent deliberate technical debt is the best case scenario, meaning that the company consciously prioritizes speed over code readability and intends to “pay the debt back” later.
So how does it affect my product?
- As the project needs extra features, more and more new people will join the team. Each of them will need time to get familiar with the codebase. The time that you, as the product owner, will be paying for. Digging through unrefined mudball of code takes quite a while and costs accordingly.
- The code will become more complex as the application develops. Each new feature will require more time to implement, integrate and test. Refactoring helps mitigate this.
How do I know if my product needs refactoring?
If your product has transitioned from the MVP stage and needs new features, you should budget some developer time for refactoring. However, if you don’t plan to develop your product after release, you can leave it as it is.
Polishing the code in advance is usually a bad decision. It could slow the team down, devour the budget needed for more important things and draw the team’s focus away from addressing the needs of the users.
From the development perspective, Bryan Helmkamp at Code Climate created a good set of markers telling you to do it.
- Refactoring speeds up the current task. If there is something you can do to get immediate rewards, why put it away until tomorrow/next week/never? It takes some skill to understand whether a certain change will pay off now, but experienced programmers can usually make the right call.
- It is quick and easy. Like the point one, if there is a quick change you can implement which helps make the code cleaner, go for it.
- The three strikes rule: if a certain code snippet causes your team trouble three times, it is time to put some work into making it simpler. This way the developers will improve things that actually slow them down.
- You are creating a problem which might cause more than a day to solve. If refactoring it later would take a reasonable amount of time, you can get back to it when you have the opportunity. But if cleaning the code in future would need a whole day or more, better do it now. Technical debt tends to accumulate interest.
Why haven’t my vendor told me about refactoring?
Assuming your project really needs refactoring, there are two leading reasons.
- The first one — they were actually doing ongoing refactoring, but never mentioned it to you. The time and budget for it could have been logged as part of other tasks. Sometimes the team doesn’t inform the customer about it because they don’t want to bore them with technical matters, as it is a . And sometimes the client is extremely uncooperative, so they do what they need to without having to argue.
- The second one — they don’t care and are happy to give you higher and higher estimates as long as the dollars keep flowing. Eventually, the costs become prohibitive and the client decides to switch to another vendor. But by that point, everyone would suggest rewriting the system from scratch, because it would be both cheaper and easier. Don’t dig yourself into a hole, if you have doubts — ask.
Being open with the customer is vital to having a healthy long-term working relationship. So ideally all the work should be done with client’s approval.
Refactoring best practices
There are ways to ensure maximum return on your investment in refactoring.
- Ongoing improvements in code readability. As the teams grow, this becomes especially important, because new members can become productive faster. It is done over the course of each sprint and is easy enough to not affect the production schedule.
- “Technical debt” backlog. Features requiring more time to improve are put there so the product owner and the team can gauge the size of the debt and choose the right time to deal with it.
- “Refactoring week”. Every 2–3 sprints and with the customer’s approval the developers take a week to concentrate their efforts solely on clearing the outstanding issues on the “technical debt backlog”.
- Unit-testing. Sometimes customers worry that changes in the code might break some of the features. To avoid that have a suite of automated unit tests which will prevent any unpleasant surprises.
Technical debt backlog
So should I let them refactor my product?
Yes, if you want to keep it. No, if you won’t scale the product or if you want to follow the 4-point startup plan.
Source: South Park
Protect your investment and spend some money on maintenance. After all, the big guys like Facebook, Google and Instagram are doing it.