You already know what a technical debt is. You know the reasons of its existence and the ways of measuring it. But how about preventing it? Here are 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 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 visualise 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 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 allow 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 to 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

A second pair of eyes comes 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 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 the 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 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 their efficiency. 

 

9. Thorough code commenting

As your project will scale and more people will be staffed, the documentation will play more and 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 them who will use it, not the developers. Therefore, it shouldn’t be done the way developers believe it should be. This is why gathering the 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 any obstacles that may lead to taking out a 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 a 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 organisation’s culture

We know from our previous article that technical debt is like 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 its 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 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 aware of its existence, you probably know the ways that will be especially efficient in your organisation. Just remember, the easiest way to deal with a debt is not to take it out at all.