Technical Debt

Copyright 2014-17 Graham Berrisford. One of about 300 papers at Last updated 30/03/2017 17:22


I know technical debt is the well established name, but it is a misleading name.

Technical insurance premium might be a better name.

And like all insurance, one has to do a risk analysis and make a judgement.


It isn't about the qualities of the current solution

It is about the costs and/or difficulties of reshaping the current solution at some future time to meet new requirements.


Do already know which future requirements will arise?

Then we're simply talking abut good design.


If not, then what best to do now?

Designing for one kind of future requirement may inhibit other kinds of change.

Generally speaking, designing for future flexibility increases complexity and has an impact on response or cycle time.

Designing for scalability often has an impact on integrity.


What if designed-for requirements never arise?

One has to weigh extra time and cost now against

         the extra time and cost of future change

         and how likely those changes are.

None of which are readily measurable.


For more on trade offs, read this paper on Microservices.


All free-to-read materials at are paid for out of income from Avancierís training courses and methods licences.

If you find the web site helpful, please spread the word and link to in whichever social media you use.