blogs & Things

Technical Debt – The What, Why, When & How Do I Get Rid Of

Shortcuts When Coding Almost Never Save Time In The Long Run

Defining technical debt, how to reduce it and how to get rid of it

 

What Is Technical Debt?

Technical debt, sometimes called design or code debt, is a concept in software development that talks about the extra risks you accumulate when using code that’s easy to implement in the short term but you know isn’t the best solution for the long term.

The ‘debt’ is the additional time you’ll have to spend fixing these issues down the line, costing staffs time and rescources.

Just as with fiscal debt, Technical debt also earns interest the longer it goes ‘unpaid’ (fixed), making it that much harder to affect true Digital Transformations.

 

Consider a software developer, working hard on a part of the code base they’re designing. Any change they make in the code will likely have far reaching affects on other parts of the codebase or documentation. Changes that are necessary but not corrected can be considered ‘technical debt’, and, until the developer (or some other unlucky individual) pay it back, will continue to cause far reaching problems.

Whilst it’s mostly a coding term, it shouldn’t be hard to see how this concept can also be applied to other job roles or processes within an organisation.

The Origins Of Technical Debt

This next paragraph won’t help you prevent or get rid of Technical debt but it’s quite interesting, so we’ve included it for you anyway… feel free to skip down to the next paragraph though.

 

The term ‘technical debt’ was first used by a man named Ward Cunningham (who actually developed the first ever Wiki).

When describing the concept for the first time back in ’92 he said:

 

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. –Ward Cunningham

 

The Three Types Of Technical Debt

Breaking down technical debt further, there are, broadly speaking, three different categories it can be classified into; naïve, unavoidable and strategic:

 

  • Naïve – Technical debt caused by naivety typically occurs when protocols and governances aren’t followed or correctly applied. Hence, it could also be called negligent technical debt. The reasons this might occur are many and varied, unfamiliarity with protocols, rushed worked, odd naming conventions, etc, etc. This kind of debt (whilst not looking to disparage junior developers) does occur more at the junior software developer level… but even the most experienced of devs make mistakes things sometimes!
  • Unavoidable – Unavoidable technical debt is caused when tools or processes get upgraded, resulting in more efficient ways of doing things. Whilst great, it does mean older processes may need upgrading to the new, achievable standards. Changes to the scope of a project without adjusting deadlines can also have the same result.
  • Strategic – Strategic technical debt, as it sounds, is when a conscious decision is made to take on technical debt, perhaps to meet a deadline or perhaps because the financial cost of the debt is outweighed by a speedier finish to a project.

What Are Some Of The Common Causes Of Technical Debt?

There are probably thousands of things which can cause an organisation to start accruing technical debt, but some of the most common are:

 

  • Insufficient briefs at the start of a project often lead to technical debt, with unnecessary or incorrect solutions needing to be re-done. This can be exacerbated further with development starting before a brief is even fully scoped out, in a misguided attempt to save time.
  • In ongoing developments or projects that are continuously improved, older solutions sometimes become sub-optimal, as better, more efficient, solutions are found. The technical debt occurs when you need to go back to fix these older elements.
  • Pressure from upper management to get a project completed quickly often leads to a build-up of technical debt, with rushed, inferior, or unchecked code often making it into the final solution.
  • If your organisation lacks strong governances or is simply unaware of the concept of technical debt, it becomes very easy to accrue it without ever realising.
  • Having a sandbox to test solutions in before pushing them live is vital in preventing technical debt. Whilst a solution might look great in theory, it’s only when it’s tested in situ that all flaws are really revealed. Writing code ‘live’ without thorough testing is a great way to collect technical debt.
  • If a solution is arrived at but not documented correctly, then the work and time required to retroactively document it can also be considered as technical debt.
  • Technical debt is very common in organisations that suffer from a lack of collaboration, where data is siloed, and junior developers aren’t mentored correctly, instead just left to ‘figure things out’. Siloed data also means parallel development often occurs on different parts of a solution, with the duplicated work being the technical debt.

How To Prevent Technical Debt

Technical debt isn’t always a bad thing if it lets you get to market faster than a competitor, but it does eventually need paying back, and that process can be painful. Avoiding as much technical debt in the first place is a lot easier in the long run…

 

  • Technical Debt Isn’t A Dirty Word – (Or two words). If your staff are aware of technical debt, are encouraged to talk about it, and know what they can do can do to prevent it, then they’ll be that much more likely to find solutions to heading it off as they go.
  • Good Governance – cloudThing are huge advocates for good governance. By taking the time to address possible outcomes before they occur, you’re heading off technical debt before it becomes an issue. Make time within your project for technical debt, schedule planning for it into your processes and make limiting Technical Debt a KPI that your developers can work towards.
  • Don’t Run Before You Can Walk – Rushing, or leaping in, is the easiest and quickest way of accruing technical debt. Make sure projects are fully scoped out, plan ahead and above all involve your developers in every step of the process. Let them set realistic deadlines with you to avoid corners being cut to meet them. Resulting in technical debt.

How To Reduce Existing Technical Debt

Reducing existing technical debt is often a long, laborious process over going back over existing work and fixing issues.

It is something cloudThing have specialised in for a long time though and would be happy to advise you on.

You first need to understand what and where your technical debt is, normally achieved through collaborative discovery workshops with your developers.

Once you’ve identified as much of it as possible you need to develop a strategy to reduce the technical debt with incremental changes and you won’t be able to do everything all in one go. When defining that strategy, it’s important you set clear delivery goals with associated metrics and KPI reporting so that everyone has a clear picture of what they’re working towards.

Then… it’s a simple case of going after it!

More blogs & Things

More blogs & Things


James Crossland in NonProfit

AI + Automation: Reducing Donor Churn & Maintaining Sponsor Interest

Churn management is a vital element of any marketing strategy, and the NonProfit sector is no exception. Knowing what to track and having a joined up view of all your donations data is vital for getting this right, and also opens the door to building innovative data-driven campaigns.   At our recent DataScience and Transformation in Charities […]


James Crossland in NonProfit

Dynamics 365 In NonProfit’s

Charities have unique funding concerns, and an obligation to spend as much as possible on their chosen cause. However, an investment in technology can offer ROI in the form of more than just improved fundraising. Dynamics 365 can help rework complex business processes, ensure compliance with stringent safeguarding and financial regulations, as well as consolidate […]


James Crossland in Tech

8 Ways Your Business Can Increase Turnover With Big Data

Understand how Big Data and Data Science can transform your business…   Big Data is the phrase that’s used to categorise any data that’s too large, complex, cumbersome or complicated to be managed and processed by conventional technology. To put that into a relatable context; being able to recommend your customers content, products or offers based […]


James Crossland in NonProfit

How To Reduce Donor Churn In NonProfits

Reducing Donor Churn doesn’t have to be a big task but does need to be a fundamental part of a NonProfit’s day to day processes   What Is Donor Churn? Donor Churn is the likelihood of an individual stopping their donations to a charitable cause for a variety of different reasons resulting in the non-profit organisation […]


James Crossland in Tech

Agile: Cutting Costs, Improving Quality & Accessing Talent

After using Agile to develop software products for several years, we thought we’d share the challenges we encountered at the start, what we did to change and the results we saw (which were ultimately uplifts in quality and efficiency)…   My development team has been using Agile to develop software product since 2007. Personally, I’ve seen many […]


James Crossland in Tech

UI VS UX

What’s the difference between UI and UX?   Simply put UI (or User Interface) are the pages, screens, buttons, icons and any other visual aspects of a website or App that let you interact with it… or to expand on that into the non-virtual world… UI is how you experience using something – For instance in opening a fridge, […]