Technical Debt

Technical Debt

Say what now?

Technical debt is a term used to imply the cost of potential rework required on a solution in the future.
- A solution implemented today that is not quite there.

Technical debt does not always refer to software build/code. But can also include the following
- Architecture/Design debt
- Process debt
- Infrastructure debt
- Testing debt

So why discuss technical debt?

I thought I'd create a separate post on this topic because yesterday I made a post on MVP - Link: https://lnkd.in/gHdj25h2

What I forgot to mention in that post was that decisions made to go with a MVP can also result in technical debt.

In money, we know there is good debt and bad debt.
- Good debt can benefit a person through capital gains, or increased share holder value, higher returns etc.
- With bad debt, if one is over leveraged, or simply unable to make their payments, it can lead to huge losses or even bankruptcy.

Similarly, technical debt can also be classified as good or bad.

The point I want to make here is...

That, as and when technical debt is noted and registered, its potential value should be clearly stated and what future cost or effort will be needed to clear the debt.

Going forward with technical good-debt or small amounts of technical bad debt can be factored into roadmaps and timelines.

The opposite can very easily derail future plans.

Something to think about.
Happy to hear thoughts.