Imagine an old bridge on a busy route.
As years go by cracks in the support beams and loose bolts appear making the bridge unsafe.
Since there is no money to make major repairs the authorities make periodic and cosmetic repairs, patching one part of the superstructure while another part develops problems.
This break-and-patch regimen can keep the bridge open and working up until one day, something gives and the entire edifice crashes down.
Software has a similar problem.
The technical debt imbroglio
When products are being built coders sometimes take design decisions that prioritize speed and cost over stability or scalability.
In civil engineering terms teams focus on quickly constructing a building that can accommodate a family of four instead of taking the time planning one that can house forty, because four people needs a roof over their heads right now.
As the codebase grows in complexity and features keep on getting added the code keeps on breaking down as it was not written taking into account all use cases.
Temporary hacks and patches can keep the lights on but they are more in the nature of using string and bubble gum.
And this is how technical debt is accrued.
Companies who are under tight deadlines to ship products rack up plenty of technical debt. This debt in itself is not a bad thing, as in a hyper competitive market time is of essence.
In an ideal world developers would go back and fix the code so that it’s scalable. But in the short term that’s not attractive and developers often slap on more bubble gum and duct tape to keep everything together, piling up more debt. This problem is frequently seen in the fast paced world of Agile Development.
In this scenario technical debt could be fatal- the product can crash frequently, take up too many resources, or have gaping security holes.
Solving the problem of technical debt
Most people think of technical debt in terms of buggy code. Nothing could be further from the truth.
Technical debt is code that becomes less agile as the product becomes more mature. The code was okay when you launched with a few features, but will break down as more features are added.
Technical debt is actually less of a coding problem and more of a cultural problem as it stems from a focus on shiny new things instead of getting the basics right. Hence developers are not the only people who should be responsible for paying it off.
Here are some strategies for ensuring that you don’t have a Greece like problem with your product.
- Segment your code
It’s a very bad idea to lump in all your code together. If you have a mobile app the code that deals with user interfaces shouldn’t have any dependencies with code that pulls data from a third party.
Writing tightly coupled code means that even if your initial code is perfect it will turn into a train wreck soon as adding new code can cause existing code to break in unexpected ways.
- Address user facing technical debt first
Businesses should be focused on customer experience, and towards this end it is critical that they keep the debt in user facing code as low as possible. If you have segmented your code, it’s a lot easier to test and ensure that user interfaces or data structures have low technical debt because their performance matters to the user.
It’s also critical to stress test those parts of your application that receives highest traffic because that can degrade overall performance of an application.
- Iterate and improve at the same time
Technical debt should not be used as an excuse not to innovate. Software constantly evolves and no one knows what future demands will be imposed on the code.
Instead of going for a complete rewrite of the code which sounds good in theory but is impossible in practice product owners should focus on improving code quality in cycles while continuously making improvements.
Avoiding perfection in software
It might feel good to write code that’s technically perfect. But it’s even better to move fast, push code out AND adopt best practices so that the code is stable and scalable.
Debt, financial or technical, is not a four lettered word. The critical thing is to ensure that there is a balance between adding new features and ensuring that the underlying foundations are firm.
