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?

Answer 1

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.

Answer 2

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.

Answer 3

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.