You already know what technical debt is. You know the reasons for its existence and the ways of measuring it. But how about preventing it? Here are the top 14 strategies that will help you minimize or even entirely avoid technical debt.
This is part two of our guide to dealing with technical debt. If you want to know what it is, why it exists, how to measure it, check our previous article.
Before you dive into our list, remember two things. First, the list can be arranged in any order. And you can (and, actually should) implement various strategies simultaneously.
1. Building small services rather than larger monoliths
Experienced developers know this very well. So do startup founders. As much as you start with MVP with limited capabilities and then add further products or its features, you should stick with a similar strategy in terms of software development itself. Dissecting the code and avoiding monoliths helps with potential bug fixing, as there are fewer dependencies. And smaller components can be reused for similar tasks, thus helping you actually save time.
2. Application of tools that visualize bugs
As you know from our previous article, tracking errors is one of the ways of measuring the level of your technical debt. But how to spot them efficiently? Your users might report to you the major ones that interfere with their own work, but there are plenty of bugs that can hide unreported for ages.
At bPol we use Sentry, a software that notifies us about exceptions and helps us quickly find and fix production errors. We also recommend FullStory – a tool that allows you to record customer journeys, find rage click moments or error messages, and users’ actions that caused them. For recording your test sessions, you can also try Ghost Inspector. But there are plenty of other tools that allow you to find bugs that are otherwise invisible in code.
3. Implementation of unit test and testing in general
This is probably the simplest strategy to implement and measure. Testing, especially unit testing, can be illustrated as a percentage of covered code. Here, the focus is on key features that will certainly stay. Features that are only being implemented for a trial, are good to go without testing, as it may decrease the speed of deploying them to the market.
4. Remembering about code reviews
The second pair of eyes come in handy in various areas and software development is no different. Having a system of code review improves the overall quality of the code. This is generally done by a tech lead responsible for a team or could be used in a form of pair coding.
5. Business stakeholders having a long-term product view
As we know, there is a big gap between what business stakeholders want and what developers can physically deliver. With a long-term approach, developers know in advance, what awaits them in the following weeks, so they are not pushed into corners. And yes, this helps maintain the code quality.
6. Regular refactoring, especially with legacy projects
Refactoring is changing the structure of the code without changing its behavior and functionality. Say you have a wooden house and you want to change it into one made of bricks. It still will function as a shelter, but the technology will differ. At bPol, we have a rule of 5% refactor per sprint. On the other side, refactoring can’t be overdone as it will slow down the development of new features.
7. Using proven and tested technology stack
Choosing an optimal technology stack is vital for success. The technical debt can quadruple in no time if the choices are not scalable or simply the support for a framework expired. It’s also important for recruitment efficiency. The bigger the community of developers using a certain technology, the higher chances of hiring someone skilled.
8. Migrating to the latest versions of frameworks
Just as you update the operating system of your smartphone, you should keep your frameworks up-to-date. We often see clients coming with bugs resulted in using platforms that are obsolete or add-ons that were not adjusted for new core releases. Just look at the evolution of PHP, or Symfony framework. In most cases, the changes are made so the platform will be more developer-friendly and will further increase its efficiency.
9. Thorough code commenting
As your project will scale and more people will be staffed, the documentation will play a more important role. If the codebase is poorly commented, it will take longer to fully settle in a project and staffing additional resources will be more expensive. That’s why all the work should be thoroughly explained, from day one. And remember. It’s not about what is in the code, but why something was done in a certain manner.
10. Work aligned with the market fit and NOT developers fun
Software is built for the users. After all, it is they who will use it, not the developers. Therefore, it shouldn’t be done the way developers believe it should be. This is why gathering feedback and understanding what clients really need is important.
11. Agile way of working – SCRUM
At bPol we use scrum for our software development, but also educate our clients about this agile framework and its benefits in other areas. Having continuous iterations allows us to deliver projects faster, with better accuracy, and much lower cost. In comparison to other frameworks, like Waterfall, we can achieve market fit way faster. And quickly react when there are any obstacles that may lead to taking out debt.
12. Quarterly assessment of architecture and tech choices
So you’ve started with infrastructure that was great for handling all of your users. But then you grow and you no longer have 10,000 users but one million. Can your infrastructure deal with all the traffic? CTOs and product owners should assess whether the choice they made requires amendments. And they should do it on a regular basis.
13. Embedding awareness of technical debt into an organization’s culture
We know from our previous article that technical debt is like a chronic disease. And that the sooner it’s diagnosed, the biggest chances of survival. Not to mention the lesser cost. In order to spot it earlier, organizations should increase the awareness among their employees and vendors. It’s also important to track any signs of debt everywhere. Not only in technology, but also in design and all other areas that may impact software development.
14. Using serverless technologies
Finally, one of the causes of taking out technical debt is data storage. Historically, servers were located on-premises. Subsequently, the tech world moved to shared services, which were more cost-efficient but still not fully flexible. Enter the cloud and serverless technologies. They allow companies to have tailor-made infrastructure that scales up and down with traffic – both reducing the cost and allowing them to quickly answer to higher demand.
***
There are other ways that will help you avoid or at least repay your technical debt quicker, easier and cheaper. As you are aware of its existence, you probably know the ways that will be especially efficient in your organization. Just remember, the easiest way to deal with debt is not to take it out at all.
