Contents
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.
Debt in ML systems
Update Nov2021. This is an aside in the context of this paper, but I find it rather interesting that [2] argues that:
“In this paper, we argue that ML systems have a special capacity for incurring technical debt, because they have all of the maintenance problems of traditional code plus an additional set of ML-specific issues. This debt may be difficult to detect because it exists at the system level rather than the code level. Traditional abstractions and boundaries may be subtly corrupted or invalidated by the fact that data influences ML system behavior. Typical methods for paying down code level technical debt are not sufficient to address ML-specific technical debt at the system level.”
…
We refer to this here as the CACE principle: Changing Anything Changes Everything. CACE applies not only to input signals, but also to hyper-parameters, learning settings, sampling methods, convergence thresholds, data selection, and essentially every other possible tweak.
References
Wiki-refs: Technical debt
- 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
- Hidden Technical Debt in Machine Learning Systems by D Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-François Crespo, and Dan Dennison. In Advances in neural information processing systems, pages 2503–2511, 2015. See https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf