Is technical debt always bad?

Technical debt refers to the cost of delivering software or services which will require rework due to known or unknown factors.

Often it is caused by choosing an easy or quick solution due to time pressures, lack of ability, negligence or a legacy system so old or complex that no one is confident in making changes to.

Not all technical debt is bad, and managing it well can yield tremendous benefits for your company but you have to be wise about incurring tech debt. Accumulated debt can eventually impact on your release speeds, frustrate the business and demoralise the development team.

Technical debt factors include postponed tasks including documentation, testing, addressing old backlogs, and compiler and code warnings. Human factors like a lack of skills, knowledge silos, laziness, over-engineering can all add to the complexity of managing technical debt, 

Types of technical debt

1. Known knowns

At times teams or individuals will intentionally do something the “wrong” way because they need to quickly deliver product to the market. Make sure the stakeholders are aware that this will inevitably slow down other feature launches later on.

Track this type of tech debt in the backlog when deliberately deferring work that needs to be completed. If it’s not tracked specifically, it’s unlikely to be repaid and will turn into accumulated design debt over time. Product owners and stakeholders should be held accountable for the accrual of this kind of debt as it’s incurred by business decisions.

2. Known unknowns

Good systems evolve more quickly than bad ones but be aware that the reward for building a successful system or service is that you will be asked for more of it, in many versions and colours so build space in your dev schedule for customising your software. Just as a car manufacturer knows that it must make each car customisable for each customer so should your product be flexible enough to meet the needs of each customer or business department 

3. Unknown unknowns

Legacy technical debt accumulates over time. Often due to trying to maintain systems that are built on old systems but are too crucial to the business to touch. They have become complex due to incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design.

Ideally to counter this we incrementally improve the design and clean up bad code along the way. The development team should be accountable for avoiding and fixing legacy debt.

Technical debt will, and should, always exist in systems. It’s essential that you try to understand how the debt is slowing your team down, and balance efforts of delivering features in the short term with increasing overall productivity in the mid to long-term.

Preventing technical debt

1. User requirements: Understanding and delivering user requirements is the number one way to avoid technical debt and the key to avoiding its accrual. Often there is insufficient up-front definition or requirements are still being defined during development to save time but you will pay for it later. These are often due to business pressures causing a product to be released before all of the necessary changes are complete.

2. Unfactored technical debt, due to a lack of process or understanding, not included in the backlog can be avoided by making all stakeholders accountable for their effects and their resolution in the risk log. Last minute specification changes have the potential to affect good design so adjust the project plan to accommodate them by planning for them, they almost always happen

3. Laziness. Call it out, whether it’s documenting code or just work someone else in the team will have to pick up as a result of.

4. Poor IT architecture. Yes, sometimes it’s the architects fault. There’s no shame in going back to the drawing board.

5. Insufficient testing encourages quick fixes and increases production risks. Write your tests and make sure they are done. 

6. Lack of documentation within code or to support the user will create future technical work made harder for everyone

7. Inflexible software which is too difficult or specialised to adapt to changes in business needs, keep your design adaptable within each module

8. Lack of skills or collaboration, where developers are asked to learn to much to do the job or the knowledge isn't shared. Ensure your team have the training to deliver from not only a technical perspective but also in a collaborative sense

9. The job has become too big. As backlogs grow so does debt, like any other project break it down into manageable parts by starting with a good redesign plan

10. New standards arrive every day in the tech world. The profession is becoming more regulated in an effort to improve standards, prevent failures, improve consumer confidence and respect privacy. Privacy by design is just one of the many new standards good developers respect.

Share this article!