Technical debt vs. technical deposit

Started 18April2016 – updated 3Mar2017
This page is in group Technology.

Technical debt exists as a term. It doesn’t seem like technical deposit is a corresponding term. I try to do something with this here.

(Observe that “depth” (with p and th) is how deep something is, it has nothing to do with “debt” that’s an obligation to pay later etc.. And there is nothing like “technical dept” (with p, that I misspelt originally))

“Technical debt” defined

Wikipedia defines Technical debt basically like this (19May2016):

Technical debt (also known as design debt or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. (References removed by me)

There are more interesting matters discussed there. Like if a short-cut isn’t fixed in time then it gets worse and worse. And like it’s not always bad, it might be a way to get things done.

The reason I got interested in this was NTNU master student  Shahariar Kabir Bhuiyan who did his master with case studies from my employer, Autronica Fire and Security, in 2016. It’s published at [1].

“Technical deposit” defined here

New term here, I believe. This should then be the opposite. I suggest something like

Technical deposit is “a concept in programming that reflects the less development work that arises when coding is done by applying the best overall long term solution instead of coding that is easy to implement”.

This definition isn’t really good enough, but it inverts the first Wikipedia paragraph – which isn’t necessarily very good either.

We can’t really run arithmetics on this. If we do something fast we won’t have time to fix it. Nothing is put in the time bank, “in the plus” so to say. Fixing is taken from other projects and will disturb them. On the other hand, if we do something correctly on the first round your manager will tell that you spent too much time and think you’re slow. Even don’t give you a raise.

  • Total work if debt = fast done + fix time
  • Total work if deposit = correctly done once

Still I like the deposit idea much more, even if the latter takes more (apparent?) time. To paraphrase somewhat with a sentence I heard many courses ago: “If you don’t have time to do it correctly now, when should you have time to fix it?”.

I argue that it’s better for the developer, the company and the customer. Even for the user. If your manager doesn’t understand this then it’s he who’s in the way.

Of course correctly done also implies to get things done in a finite amount of time. I think that if the manager lets you do it correctly it also get done in a finite amount of time because stress is more on the matter and not on the shoulders.

In a product we released given versions on agreed dates, but only with what was present at those dates. What wasn’t ready wasn’t included in that build. I wrote something about this in a magazine (here, in Norwegian. It’s entitled “We had so much, we made this. But do they get?”). I think this was a good way to build that project. But the organisation needs to have confidence in the developers for this to work.

“Technical deposit” defined for something else

A quick search on “technical deposit” gave me this at a company called Syvecs in the UK. It’s a chapter subtitled “Pin outs, sensor calibrations etc”. It’s not even close to the usage above.

References

Wiki-refs: Technical debt

  1. Investigating Design Debt in Safety-Critical Systems: A Case Study by Shahariar Kabir Bhuiyan. NTNU master thesis (2016), see https://brage.bibsys.no/xmlui/handle/11250/2406935
Email this to someoneShare on FacebookTweet about this on TwitterShare on LinkedIn