6

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: softwareengineering.stackexchange.com/a/350978/197567 – user783836 Jun 17 '17 at 5: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. – user251748 Mar 30 '18 at 17:37
7

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.

  • 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
  • 1
    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
  • 2
    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. – user251748 Mar 29 '18 at 19:28
4

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. – user251748 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 0:14
  • … who can build with a dollar what any fool can build with ten." – Jörg W Mittag Mar 30 '18 at 0: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. – user251748 Mar 30 '18 at 15:03
  • Well, useful or not, that is the definition. – Jörg W Mittag Mar 30 '18 at 15:48
1

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.

  • 1
    "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
  • 2
    @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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.