Does every choice incur technical debt?

Question

I'm familiar with the concept of technical debt as the cost of effort (through maintenance, support, rework etc.) incurred when choosing an expedient solution over a complete one.

What I am wondering about is, is technical debt incurred for any choice you make?

Take for example securing an existing application that never had any security previously. Imagine that initially the requirement is simple enough - there are admins and non-admins. Admins can access the admin area and non-admins cannot. At this point the team has a choice,

implement a simple security model e.g. a field indicating whether a user is an admin or not and restricting application access on this field or
implement a complete security model e.g. roles, permissions and groups and associated application hooks.

The costs attached to the implementations are:

the simple model. quick to implement (5d), but the cost of adding and managing additional roles e.g. supervisor, manager etc. and applying them throughout the application is expensive (5d per role)
the complete model. longer to implement (20d), but the cost of adding additional roles should be minimal and the cost of applying them throughout the application is lower than the simple option (1d per role)

I get that by choosing the simple model I am saving 15d on the implementation time but incurring a technical debt of 4d for any additional roles.

If I chose the complete model I'd incur an additional 15d of implementation cost, but am I incurring any technical debt?

The question is not logical. We make choices continuously as we develop software. If "technical debt" (flaws) were incurred at every choice, we would never be able to develop large software components. Since we can do this, clearly we don't need to incur much technical debt as we develop. — Frank Hileman, Jun 16 '17 at 22:04
@FrankHileman Some arguments (see below) have been made that technical debt is indeed always incurred when developing as your knowledge and understanding of the domain is imperfect: https://softwareengineering.stackexchange.com/a/350978/197567 — user783836, Jun 17 '17 at 05:03
Read the original explanation by Ward Cunningham. The metaphor is a flop because he is figuring that programmers will learn as they go and gain understanding. But in business, the customer wants experts to make a known product, they are not paying for OJT. In business, if you don't already know how to do it right, get out of the way and let someone who does know do it. Thus, technical debt should not be a thing. It is a failure, not an expected occurrence. You don't expect a new pilot to crash some planes or fly around aimlessly for a while, you expect them to fly point A to point B correctly. — , Mar 30 '18 at 17:37
@user783836, In every place where I ever worked, "technical debt" did not mean defects. Technical debt meant poor design choices that we were forced to accept because we couldn't do something the "right" way if we were going to meet a mangagement-imposed deadline. Technical debt was problems that the customer never would know about—problems that we would have to face in the future, when management wanted a new release with new features. — Solomon Slow, Feb 15 '22 at 22:25
The fundamental reason we don't always incur technical debt every time we make a decision with our imperfect knowledge is that, sometimes, we get lucky. — candied_orange, Feb 15 '22 at 22:32

score 8 · Accepted Answer · answered Jun 15 '17 at 12:16

8

Technical debt means you are in debt. If you complete your task (for example Admins/Users) and it works and is secure and easy to maintain, then there is no technical debt.

Not being able to foresee potential future developments, new features or changes are not what is meant with technical debt. Always compare to the solution, needed to fulfill the current requirements.

To use the famous car analogy, technical debt is when your brakes leak and you don't have money to fix it. If you own a perfectly good Volkswagen (not Diesel...), then not owning a Ferrari yet is not technical debt.

answered Jun 15 '17 at 12:16

nvoigt

7,737
3
23
27

2

Debt is when you are taxi driver but have no car. You need a car to earn money, but you need money to buy a car. So, you borrow money, buy a car, earn money, pay off the debt. Technical Debt is when you are a car designer and you need to build a body in order to test it in the wind tunnel, but you need the results of the wind tunnel tests in order to know how to design the body. So, you design the body the best way you know how, test in the wind tunnel, then use that new understanding you gained to change the body as if you had known from the very beginning how to design it. – Jörg W Mittag Jun 15 '17 at 14:59
Technical debt is building something the best way you know how based on limited understanding in order to gain a fuller understanding. – Jörg W Mittag Jun 15 '17 at 15:00
2

A definition I have seen a lot is "A design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)". Under that definition neither the first nor second body design are technical debt since in neither case did you choose an expedient option. You chose the only one available. – user783836 Jun 15 '17 at 15:50
4

The examples in the answer and comments don't approach the most important part of the metaphor: the interest accruing on the debt, i.e. the ever increasing time spent dealing with shortcomings in the design. – whatsisname Jun 15 '17 at 16:01
But if the Ferrari costs the same (or less than) the VW, and you don't investigate that before buying, and everyone who knows anything is buying the Ferrari, then you buying the VW is also technical debt, through ignorance. – Mar 29 '18 at 19:28
There are multiple types of technical debt (Strategic Debt, Accidental Debt and System Rot) So having strategic debt is not necessarily bad https://innovationarchitects.wordpress.com/2018/09/02/technical-debt-the-prime-killer-for-innovation/ – MuSTaNG Sep 06 '18 at 09:09

score 6 · Answer 2 · answered Jun 15 '17 at 15:13

I'm familiar with the concept of technical debt as the cost of effort (through maintenance, support, rework etc.) incurred when choosing an expedient solution over a complete one.

That is not what Technical Debt means.

Technical debt is a financial metaphor (Ward Cunningham worked on a financial product when he tried to explain the concept to a manager, so he chose a financial metaphor that would be familiar to him.) Say, you want to go into construction. You need machines to earn money, but you need money to buy machines. It's a catch-22. How do you break this? Debt! You borrow money, buy machines, use those machines to earn money, use that money to pay off your debt. If you don't, you will accrue interest and your debt will be even higher.

Technical debt is related to understanding of a system: in order to design a system well, you need to fully understand the system. But, more often than not, our understanding of what we are about to build, is only partial. In order to gain more understanding, we would need to observe the system, play around with it, use it, etc. But, of course, in order to do that, we need to build it first … but in order to build it well, we need to understand it first … and so on. So, in order to design the system well, you need experience with the system, but in order to gain experience with the system, the system needs to exist, i.e. you need to already have designed it. Catch-22!

So, what do you do? You design the system the best way you know given your partial understanding. (You take on technical debt.) Then, as you understand the system better, you refactor it so that the design looks as if you had fully understood it from the start. (You pay off technical debt.)

It is very important that technical debt means "build the system the best way you can, given your partial understanding". You must design your system well, otherwise you limit your ability for refactoring your newly-gained understanding back into the system! It does not mean "build something shoddy, just to get something out the door". If you know a better way to do it, it's not technical debt. Technical debt means that you don't know a better way to do it, because you need to build it first in order to understand what would have been a better way to build it.

I would not call what you are describing technical debt. What you are describing is simply the YAGNI principle: don't build something because you think you might need it later. Only build something when you actually need it right now. What if, after using the system with an admin/regular user split for a while, you realize that you don't actually need a role-based system but a capability-based system?

You could interpret it as technical debt if the discovery that you need authorization was made through using the system. You would never have known that, if you hadn't built the system with limited understanding first.

Yeah, I always thought of it as the opposite: you know a better way all along but choose not to do it that way. Debt is something you choose, like buying a house. You don't just wake up one day with mortgage papers sitting on your bed, because you didn't know any better the day before. — , Mar 29 '18 at 19:24
But you do choose! You choose to build the system, even though you know that you don't fully understand how to build it yet. Of course, what you are talking about, also exists, and is also important, and probably also should have a catchy name … but it is not Technical Debt. Actually, depending on the circumstances and your exact definition of "choose not to do it that way", and most importantly, the reason for "choosing not to do it that way", I would simply call it a tradeoff, or even more general, just engineering. Remember the definition an engineer: "An engineer is somebody … — Jörg W Mittag, Mar 30 '18 at 00:14
… who can build with a dollar what any fool can build with ten." — Jörg W Mittag, Mar 30 '18 at 00:14
But it was not technical debt when bronze age people did not make iron implements because they didn't know yet how to work iron. Otherwise, all technical debt would be infinite, after all, space aliens who can go faster than light have already solved all of our problems. Or we will some day, and so we are all as dumb as rocks, and that means lazy eight technical debt on absolutely everything! Not useful definition. — , Mar 30 '18 at 15:03
I once read that if we tried to 'outlaw' inflation, then the entire economy would halt, because there would be no incentive to do anything that would pay off more later. No one would invest in anything, because all that would mean is that they deprive themselves of purchasing power now and gain back exactly the same amount later - stupid, right? So, the world is based on the same principle as walking: pitch forward and catch yourself, pitch forward and catch yourself... The idea is that we expect to get somewhere. In software, we expect to learn. But if we don't: no incentive, no debt. Stasis. — , Mar 30 '18 at 17:27
If someone didn't know better, they did not make a choice to incur debt. If they do not learn in the process, they still do not know better. No debt. If we don't realize that we can instantly move across galaxies, instead continuing to burn dinosaur blood, no debt. If we never develop fusion, we do not have any technical debt now, in terms of "could have done better", and we never will. It is not a forward-looking evaluation, it is a backward-looking one. Or sideways, if someone else does know better and we don't get their help. — , Mar 30 '18 at 17:29

score 1 · Answer 3 · answered Jun 15 '17 at 12:37

What you present is not what I'd call technical debt at all; it's an architectural decision which can only be made given the constraints you're designing the system under. If you are expecting to only add a single role during this system's lifetime it makes no sense to go for the second solution. Likewise, if you are expecting to be adding lots of roles you'd be stupid not to go for the second one.

Technical debt is the intentional implementation of a solution which you know won't hold in the long run but which is good enough right now. Perhaps that time could be better spent elsewhere so you hack together something brief, delaying the inevitable moment when you'll have to solve the brunt of the actual problem.

In your case it would be going for the first solution when you actually need the second one, yet time constraints (or something else) forces you to go for the immediate simple solution which will work since you only expect to be creating a single additional role in the coming month. Now you have incurred technical debt because you have chosen a solution you know won't hold in the long run.

One of the key elements I associate with technical debt is that you've actually coded a solution which is subpar, can't be extended to do what might be necessary in the future or which definitely can't scale in any meaningful way meaning (at least not in the way you need it to). You've intentionally created a ticking time bomb.

If you implement a technical solution which you're confident in will solve the problems it was intended to solve then there is no technical debt associated with it. As always, requirements can change at a later point but that is not technical debt.

On that note, don't be afraid of incurring some technical debt.

In my company have learned that lesson the hard way by spending too much time on functionality which time has shown to be throwaway code; the type of stuff you could've gianed more monetary gains from by programatically compiling Excel sheets and throwing them at a sales team.

"Technical debt is the intentional implementation of a solution which you know won't hold in the long run but which is good enough right now." – That is not what Technical Debt means. Depending on how "responsible" you are when making that decision, I would simply call it "good engineering". (Remember: "an engineer is someone who can build with a dollar what any fool can build with ten.") If you intentionally build something one way even though you know a better way, that's not technical debt. Technical debt is if you build something the best … — Jörg W Mittag, Jun 15 '17 at 14:53
… way you can, because you need to build it first in order to discover whether or not there is an even better way. Technical debt is if you build something with limited understanding in order to gain a fuller understanding. In your example, the engineer understands the problem fully, he just chooses to be efficient. That's not technical debt. — Jörg W Mittag, Jun 15 '17 at 14:55
@JörgWMittag: maybe that's not what that writer means/meant, but that's what everyone else in the world has interpreted it to be. Debt implies something has been borrowed, and in the case of technical debt, what was borrowed was time. — whatsisname, Jun 15 '17 at 16:03

score 0 · Answer 4 · answered Feb 15 '22 at 21:48

According to contemporary research, this might be the case, but the definition of technical debt we are using might affect how this happens.

Originally, Cunningham used the technical debt metaphor to illustrate the difference between a waterfall-like and an incremental development process. Waiting with development until all requirements are known, are architectural decisions are taken, all optimizations are done, etc ... will optimize the coding part. Compared to this, if development starts when only a subset of the requirements are known and adapting as new information becomes available, could deliver more value faster ... but might also lead to changing code that was already written (deprecating interfaces, etc...). Please note, that this definition is not about bad code, in every iteration, it assumes the best possible code that represents the developer's understanding.

From this point of the observation of Hanssen et al. (https://ieeexplore.ieee.org/document/8785983) might be interesting to consider. They pointed out that even systems that were seemingly written perfectly to fulfill their requirements, can later accumulate technical debt when the world around them changes. "However, with the advent of open banking and PSD2, the workload may quickly rocket. This leads to tougher scalability requirements and accumulated architectural debt, despite previously sound architectural decisions."

Using the contemporary definitions of technical debt, where it seems to indicate some kind of coding/design/etc... issue in the product, the technical debt amount might also change for external reasons.

it was already shown that different tools use different definitions for technical debt and so might show different results.
research has also shown, that the values measured by such tools might not easily correlate.
sometimes are off by a multiplier of 20.
as the tools themselves continuously evolve, changing to a different version might result in very different technical debt values. If the detection algorithms are made more precise, the numbers might decrease, if new detection for new issue types is added to the tool, the numbers might increase ... even on the exact same source code.

When we looked into how precisely this situation is handled in research papers, we found that it is not common (at least among the papers we checked) to precisely identify the tools used by the researchers, what would have been needed to make the results reproducible: https://www.researchgate.net/publication/357875475_Reproducibility_in_the_technical_debt_domain

As such not just the choices inside of the product, but also the choices outside of it (how the requirements will change with time, what tools are used to measure technical debt, and so on) might have an impact on the "technical debt" of the same code.

score 0 · Answer 5 · edited Feb 16 '22 at 22:26

In normal life, debt is money that you will have to pay in the future, whether you like it or not. You can have debt because you borrowed money, or because you caused damage that you need to repay, it is all debt. Your example is interesting: Say you have the choice between buying a car for $20,000 in cash, or buying a car for $10,000, paying $5,000 now and $5,000 next year. Clearly the second car is a lot cheaper. If you buy it instead of the $20,000 car, you have $15,000 more in your bank account, but you have $5,000 in debt. It is debt. It was also a decision that saved you $10,000. (And that matches your numbers, so you have situations where entering technical debt is the right decision).

In software development, technical debt is work that you will have to do in the future. No matter how this happened, and it doesn't even matter if you don't know about the debt.

You can have technical debt because even with the best planning, the software you created is not perfect and needs changes. You can have debt because you had to move a product out of the door. You might say your to your boss "it will cost us $100,000 to do it correctly now, or $20,000 to create a mess and fix it later", and your boss might say "you are probably right, you know more about writing software than I do, but I know that the company doesn't have $100,000, so if we try to do it correctly now, we will go bankrupt. If we save the $100,000, we hopefully will make enough profit to fix it later".

Or you can have technical debt because the developer you replaced knew he was leaving, didn't care about quality, hacked something together, got a bonus and left, and you have to pick up the pieces.

Does every choice incur technical debt?

5 Answers5