I'm not particularly fan of one person coining a term and have everybody agree on that, I think every team should create its own glossary of terms and always compare against different authors that may have gone deeper analyzing a given topic. There are some terminology that makes sense for some contexts and other that simply not. It may make sense for me to call something in a certain way because my team understands and we all have agree on what are we referring to, instead of having someone to tell us how to call things.
I really like this kind of epistemological analysis on tech terms, specially those that we use all the time and that we think we understand, but mainly for going deeper on a topic and analyze.
Great point. If we name things, we should understand what the name means, and just as important, what it doesnt mean. We all know naming is difficult, which brings to mind the old joke -
"what are the 2 hardest things in technology?"
"Cache invalidation, naming, and off by one errors"
I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title.
Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept"
However, there are generally accepted meanings of the those terms for the technical debt:
- The "principal" is how many things is wrong with the code. It could be measured in features ("We need to implement unit tests and database layer to clear technical debt") or in time ("it will take 6 FTE-months to clear our technical debt")
- While "interest rate" is rarly used, "interest payment" is common -- this is extra time spent implementing the new feature. One can say: "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"
- Not all debt has fixed term. "revolving debt", like a credit card, has no term at all. Technical debt is like that as well.
(Of course getting the actual values for "pricipal" and "interest payment" is very hard and no two people are likely produce the same estimate for them. But even if don't know the values it does not change the fact the the terms are defined well -- so this is very much a "debt")
As for "not even technical" part: I am going to argue that everything indirectly affects competitiveness, costs, customer satisfaction etc.. A leaking roof will decrease morale, decrease development speed and can even kill the company. Judging by consequences does not really bring anything useful to the table, so if you want to qualify the term, let's use originating action. "Technical debt" if we don't have any tests. "Financial debt" if we took money from the bank. "Organizational debt" if we are not creating the positions we need, and so on...
You make a god point about the generally accepted meanings for terms for technical debt. However, there are lots of companies ive worked in (and more I know of) that try to scientifically calculate a numerical value for Technical Debt. At best, it's a metaphor, a mental aid to understand a loose concept. Any attempt to calculate implies that there is some 'best solution' that should be achieved. However, this almost never exists, any best solution is in the eye of the beholder, it will differ depending on whether you are a developer, DevOps, client, manager, CISO, barista, best friend, pet.........
That’s because abstraction enables a mental model and a language around the translation of your domain to computation.
When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression.
In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are multiple ways of expressing the same.
Quantification of unnecessary complexity can only be done after you know what is necessary and how you express that.
While there may not be some universal best solution, that does not mean all solutions are created equal. You can certainly look at two options and say "this one will take about half as much effort to fix later" or "it'll take as much time, but we can put a less skilled person on it." Maybe putting a number on it doesn't mean anything in absolute terms, but it's still useful in relative terms.
Nice analysis, but I think you missed the most important difference between real debt and technical debt: with real debt you owe someone else; with technical debt you owe yourself.
Not to yourself; you often inherit the debt from previous developers (who may have left).
The project accrues technical debt.
And it owes it to the users.
Because, ultimately, that's who all these FTE hours (the currency borrowed!) are going to.
By taking a shortcut now, you make an implicit promise to the user to rewrite things later (on behalf of the project).
It's the user that suffers if the debt is not repaid (by experiencing bugs, missing features, slow releases, paying for higher headcount to fix bugs, etc).
Shortcuts don't become debt unless the user is affected. If it's stupid and it works, it's not stupid.
And it is the user that will dump your project if that debt is never repaid.
I had an aha moment a few years ago when I realized that technical debt is not taken out by the development team; the development team are the ones making the loan. The debtor is the product/sales team, who got their feature early but now have to pay a little more (in delay or lack of functionality) for every other feature.
Ideally, a dev team delivers feature value at a particular sustainable rate. Think of that as your product team’s ‘income’. Now, if the product team needs a feature early, they can have it if they take out a loan - they can have the feature built without sustainable integration into the codebase - but it will reduce their effective income because future feature delivery will be slowed by the friction of the incurred debt - the interest payments.
Don’t let the product owners make you feel like you have to deal with the burden of debt they took out! They owe you the time to clean up the mess they demanded to get their features faster.
> "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"
Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.
For example: "Implementing the database layer properly would have taken 5 days; because we took shortcuts (for business reasons) it only took us 3 days. Now we have to implement feature X, and because of our previous shortcut feature X will take 4 days, so 3 + 4 days in total. But if we had implemented the database layer properly in the first place the new feature would have only taken 1 day, so 5 + 1 days in total."
Then in the three-day payment, two are towards principal (that's how much you "borrowed" previously), and one is towards interest.
> Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.
I didn't read the GP as saying that they were paying down principle. They don't say what the hypothetical feature is, but my assumption was that it's a feature that they could implement without a database layer but that would be faster if they had a database layer. That is, I assumed that even after the 4 days of development for the new feature, they still won't have a db layer – which is why the extra three days is pure "interest".
Bankruptcy metaphor is applicable too: when enough debt accumulates, all the capable engineers start leaving the team, and newly hired once never stay for long. The project will either get scraped as unsuccessful, or rewritten/replaced with another one.
This is why it is important to refactor dangerous system deficiencies sooner. If tech debt takes 2 weeks to clean, one can always squeeze that into the plans. If tech debt takes 1 year to clean, it is nigh impossible to persuade the business give that much time.
Ok, so the article basically said to comment before reading. So technical debt is anything in your codebase or infrastructure that makes things harder in the development process or limits the set of features that you can offer. You live with it because this limitation is not completely blocking, otherwise you would actually fix it, but you also don't want to forget about it or pretend like it doesn't exist. So you track it and call it technical debt, it's effectively an IOU to your future self.
The idea that debt has a specific and clearly-understood principal, term, and interest rate is a very narrow corporate-finance perspective. Many forms of debt in many cultures do not work like that (consider the notion of a "life debt"); you have a fuzzy sense that so-and-so owes so-and-so, but no specifics about exactly what or how it would take to repay that.
Technical debt is not corporate debt but it is debt. The metaphor succeeds mostly because it's accurate.
A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong".
B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at some point and uses this to say "it's not technical because it's business". But it is technical because, well, it is issues with your technology. That you borrowed on your tech stack for business reasons doesn't make it less technical
C) ironically I'm arguing on semantics because I find the title to be semantically wrong. In fact I largely agree with the point of view, tech debt is the result of a strategy, be it that you want speed or low cost. Sometimes it makes sense for the business, and as long as the strategy is conscious and explained, and that we're clear with the consequences, I'm fine with it. In my experience most of the time it's not an assumed strategy and we dont want to deal with the consequences.
It is important to occasionally have arguments to clarify semantics so we maintain the meaningfulness of our language. Otherwise, we lose the ability to communicate.
Some people believe that meaningful communication is unimportant. Those people are wrong.
We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me".
Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is.
Furthermore, what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.
> what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.
I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.
I agree that there used to be an overlap between an academic and a programmer. But as you pointed out, it hasn't been the case for a long time.
Plus, I'm not really sure good practices mattered to them even back then. Academics, whether they're programmers or not, chase different goals and have other incentives.
Like you, I'd love listening to one of them one day (if anyone speaks up). I'm sure there will be a few pearls of wisdom in such a shared experience.
I have some experience with older financial and edu systems, and it's definitely a different perspective (from my perspective).
If you have a system that's been modified to handle every edge case encountered in the last decade, and it works, and other people rely on it to do their work, your perspective switches to maintaining the environment the system operates in.
You're looking at automation continuously built around processes that might predate electricity. The interfaces are ingrained into the organization. Other organizations rely on these interfaces and sometimes there are legal responsibilities.
It's a longer-term perspective. Tech debt isn't a crisis, it's an eventuality you try to encapsulate.
I don't disagree with the article, and I don't disagree with you - I'm more of expanding the ideas you discussed.
I think the key here is indeed that technical debt should not be used as an excuse to write poor code.
But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market.
It "is accepted" that the most of the cost a software comes from the maintenance period - adding bugfixes, new features, and just reading the code.
If the software can be moved from point A where these costs are high (including risk of things getting broken due to complex architecture) to a point B where they are lower, then I could say "technical debt is paid back".
Was the software in point A due to intentional shortcuts, or just because that's how we write software in an unfamiliar territory, is maybe besides the point in gauging the practicality of the term.
The "technical debt" gets anyway accumulated due to the empirical quality of most of software engineering process.
I think this is the most critical thing people should realize - don't take short cuts unless the house is burning down - but do try to explore the problem space fearlessly.
The exploration is due to incomplete understanding of the end user needs. And sometimes you can't really explore that space without delivering something to the user.
But!
I think the exploration phase does not necessarily need to incur technical debt if it's done using prototypes that won't end up in production (yeah yeah like that's ever happened but in theory...).
In this case the deliverable will be just used as a template for the actual product development, with the result that the product may be in a more mature state from the get go, and hence, have less debt from the start.
Should the exploration be done with prototypes or actual vertical slices of production software? I suppose this depends on the situation. Sometimes the problem is actually so hard that you need to deliver a build based on an actual production codebase no matter what.
I think in general writing code based on hypothetical requirements that never materialize is just wasteful. And leads to bad code.
You can ship good code fast.
Shipping slow is not a guarantee of good code.
I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.
This isn’t about knowing what changes will be made just that change is inevitable. Technical debt arises because it’s faster to write brittle code.
The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that section.
Yes, I 100% agree and would like to add to your argument.
Another example of technical debt is when you write code without tests. You’ll probably finish much faster in the first week or two and then the manual testing will take more and more time. But how often did we see code bases without tests? All the time! And the managers don’t realize how much money they could save by focusing more on quality instead of features.
If you think you‘ll just implement this one thing and then never touch the code again, chances are high you‘ll just hack up the thing and copy paste some code everywhere until it kind of works. This is increasing technical debt, you take out a loan and someone in the future has to pay it back IF they want to make a change. But this is almost always the case, even if you don’t know it now.
My definition of technical debt I wrote down before reading the article: technical debt is the inability to make changes due to not making changes (on a conceptual layer) before.
This is silly. Debt doesn't just have to be monetary. Or can we no longer say "I am in your debt" because we can't accurately estimate a monetary amount for that debt?
Surely this discussion will ultimately merely degenerate into prescriptivists vs descriptivists?
For my part, I use the term sparingly since I find I can easily use it as a catch-all thought-terminating cliche. That doesn’t mean it is useless. Just that it’s bad for me to use it.
People around me know to not let me get away with saying that.
things for which analogies are made are not actually 100% the same as the thing the analogy says they are like, that's actually sort of the point.
and I say that as someone who doesn't much like analogies or metaphors for most code management issues as I think they often obfuscate the problems more than they illuminate.
Technical debt is when you effectively borrow your future self's time and effort by taking a shortcut now that your future self has to work for to pay for it.
It is literally a debt. I dont know what the article is trying to say, it sounds to me like something my boss would say after a 2 hour meeting in a delirious caffeinated state, but thats probably just because I am not familiar with the corporate use of the term "technical debt".
this article takes the metaphor way too seriously. At best, this is language we can use to help clarify what things we need to focus on and the trade off, most often useful when describing things to non technical people. At worse, it can be taken in such a way that we try to quantify the debt so it can be seen how badly things are screwed up. Its not a metric and doesn't really have a strong definition, it's more conceptual.
IOW, for me technical debt is "the debt" as seen from the engineering team. While the cost of the debt is something the management takes care off (and so decide to clear it, buy it, or whatever).
Debt in business is a well-known and appreciated way to get things moving now at some additional cost later.
This applies to both financial debt and technical debt. The difference between those, and hence the name, is how you incur and repay it, not how you make the decision. It's not "business debt" because you can't repay it with "business".
If I were to imagine "business debt", it'd be making decisions now that work well for the moment, but won't work well in the future and will actual retard the business for a while later. You could do it the "right way" now and have fewer customers up front, or you optimize for now and have more customers now, but make it harder to get customers later.
Likewise, financial debt gives you more money right now and costs you more money later. Technical debt gets technical stuff working right now, but takes more time from your tech team later when you need things to be different.
I tell all my coachees not to use "technical debt" outside of technology, if ever. Same goes for the phrase "refactoring", don't use it outside technology.
"We outgrew the choices we made that allowed us to grow fast, and need to refresh our product to sustain the growth rate" = actually means what we want to say
Makes it clear that prioritizing new features will come at the expense of growth. Which is ultimately what the stakeholders really care about.
It's not a good term, but the meaning is clear enough. You can't keep sweeping things under a rug indefinitely, your ass is due for some biting because of accumulation of poor decisions.
As a believer in tech debt the centrepiece of my disagreements with non believers does go to the nature of debt and interest: they don't believe you accrue any extra burden delaying work to the end. I do: the accumulation of technical delay, imposes additional costs which would not have existed had you amortised the update across time. Complexity, tooling, shifts in underlying dependencies all become worse the more generations against "current" you have to transit.
It rarely costs less to delay tech work. It often costs more. The "moral force" of the debt analogy is strong.
And you can get the debt vindicated too, by being unable to further develop or deploy the software due to changing environment or requirements, especially in a timely manner.
Tends to happen at the worst of times when you're least prepared.
We can discuss meaning all you want, but I'll still get my managers asking me to write code quickly now and take some shortcuts, and telling me to write a "Tech Debt" ticket to fix it in the future.
Much of the time "technical debt" seems to be a euphemism for bad engineering
The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt"
In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our business strategy all along.
Not all technical debt is bad engineering - some is great engineering that you do, knowing it won't scale or be fit for purpose forever (but it's right to do at the time, because it meets another goal - for instance speed to market, flexibility, stability, cheaper).
Software is very different to building the millennium tower - that's designed once, and when built won't be expected to substantially change or grow (at least from a structural perspective, you will change the interior). Building a skyscraper can take 5 years to complete, and when it's built it looks like the design from 5 years ago (with all the same load assumptions). With software the design is expected to change throughout the lifecycle, and should adapt to customer demand and scaling requirements, and you can't wait 5 years for perfect when 'good enough' will do and get you live.
Maybe it makes more sense to look at concrete examples. Twitter using the db as router (and rails in general), was a reasonable decision for the MVP. They got it fast and cheap.
For social media kind of traffic it became inadequate at some point and the debt had to be paid (and thanks to success was easy to pay).
A concrete example might be choosing a database and schema for a public-facing product with the hope that it'll become popular but with no architectural contingency plan whatsoever for how to scale up that data storage in the event of success
Certain qualities or features like horizontal scalability and security can be relatively inexpensive to design in at the beginning and immensely expensive to try to tack on later once a system is already in wide use.
Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle.
Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot of buildings have little spaces reconverted to closets just because there was leftover space there. That's technical debt, you know the "best approach" (according to waterfall engineering) would be to find out how things will work and then build it, but you'd rather write "IOU" on that section and move on to the important bits. You can then solve the kinks with plasterboard.
The best example of technical debt is code that doesn't scale. You know you should write your code to support 1M users, but you currently have ~100 users. Instead of spending a month serving 990k users you don't have, I would say it's good engineering to solve the problem for say 10k users if that means you'll spend a week, and have the rest of the time to solve other more pressing concerns.
Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time
I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.
You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.
Most teams I have encountered so far don't have an anyone that experienced with scalable database systems. So you have to choose the best you can do at that moment without loosing your momentum. When more users come more funding will come and you can hire someone who can repay the technical dept chosen before.
Agreed that it's a result of not having people experienced with building systems at scale.
That's not a technical choice since the person writing code wasn't aware of the options, so it's a business choice. How good of a business choice is it, though?
We all know at some level that a well-intentioned but inexperienced engineer can make a decision in an afternoon that will take weeks or years to clean up. I often see junior engineers spend several days over-engineering something that a senior engineer would have done simpler and better in a fraction of the time. I don't think it's a given that junior engineers provide better return on investment early on that a senior engineer.
Getting some worthwhile feedback and advice from a seasoned engineer doesn't need to cost a fortune in up-front cash, and personally I think it'll pay for itself. You either compensate them with stock or hire them as a temporary or part time consultant.
> Cunningham: I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.
Technical debt is not about technology, but about better understanding of functional domain, after which you should refactor your current implementation to better reflect reality in the sense that there is a more clean abstraction and accompanied code.
That's just one part of it. In modern development practices you have dependencies, each being at risk of getting outdated or insecure. Even if it's the programming language, build environment or OS.
I'm in the process of searching for an apartment to buy and the formula for calculating the installment amount, while using only basic operations, is anything but simple.
Chiefly the answer to the question "how will this amount change if the interest rates go from effectively zero to 6%, which is the 30-year average?" is not straightforward.
A nice over-complication of a simple problem.
The developers took shortcuts to meet deadlines, there is now debt in the code.
You can make it as complicated as you like but the term fundamentally represents the above in reality.
> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense.
This really is NOT how you start an article. You only come across as needlessly assertive and arrogant.
> Nobody explained technical debt; we assumed it was a fundamental property of the work.
Total BS. Literally every manager I ever addressed in a sentence where "technical debt" was mentioned did question what exactly it is and why do we need to address and "repay" it. Where is the author of the article living? Not with us the programmers here on the ground, that's for sure.
> Now, one major concern in academia is rigor.
Ah, so now it's about academia and its definition. I'll cut him a deal. Bring your academics to my former customers and see if they can override management's idea of a technical debt. Succeed 5 times and then I'll bow to you and accept your definition. Until then you're just an annoyance like that guy on parties who is always going around telling people "well ACTUALLY you are using the wrong term".
Doesn't matter what the dictionary says, people. It matters what most of the people think a word means. It matters what most of the people do when faced with the word. Why is this so hard to accept for many?
--
No, I haven't read the entire article. It smells of intellectual elitism and arrogance a mile away. The author must work on his tone.
Technical debt, whatever your definition of it is, is still a natural property of tight schedules. That's it. We can all go home now.
I wouldn't expect an academic to understand realities of schedules and budgets though.
I really like the opening question because it is a forcing action that will allow you to agree or disagree better.
My initial thought was that, as academics, they were going to be aloof and out of touch. However, as a boots on the ground dev who has worked from start up through multi-thousand employee public company, and who has held leadership roles, I agree with the article. Maybe if you read it, you would too.
I've given very compelling arguments to address tech debt that made a room of 20+ people in management smile and nod approvingly. Yet higher leadership still overruled me (and them).
If not, I am not convinced the article has anything to offer me in particular.
I think the whole term "technical debt" has developed as a part of business and technical team negotiations. The technical team prefers to improve their own job comfort, doing tasks that make their job more comfortable and stress-free, but doesn't really add business value in terms of revenue and profit. The business side isn't aligned against this work, but their priorities are on the other side. "Technical debt" is a great term from negotiation viewpoint, because for clueless business leaders it gives the impression that the tech team is paying debt when it is doing this low-risk low-reward activity, when it actually isn't.
1. Is "technical debt" debt: If it walks like a duck...
Not all debt is in the form of retail loans. Leaving a "IOU" note where someones lunch was, is a form of debt (a very dangerous one). Good luck trying to find out your interest rate in advance.
2. Is "technical debt" technical: If we follow the author's logic, I guess now financial debt is not financial. Financial debt will also affect:
- Competitiveness by slowing/speeding up new product development.
- Costs (short-term decrease/long-term increases in development cycles)
- Customer satisfaction
- Whether a company can survive
That's the point altogether, "technical debt" behaves in similar ways to financial debt.
My pet issue with technical debt, is what happens when engineers are allowed to pay it down.
In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time.
Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equally problematic.
In the worst case, you have a combination of ignorance and best-practice-hysteria that gets applied to actually-fit-for-purpose code. Then the 200 lines of performant and correct code that takes two hours to fully understand, gets turned into 2000 lines of deeply nested class hierarchies mixed with immutable FP-wank that takes several days to get a grasp of and both fails to handle real-world data (“not in the specification!”) and tanks system performance (“premature optimizations!”).
That's what you get from inexperience not from paying off the debt.
It's called second system effect and it's relatively easy to avoid by methodically documenting original and mercilessly avoiding adding features.
And this includes design features that are not immediately shown to save a lot of time and code.
Every such feature needs an advocate and also a prosecutor, and alternatives have to be briefly explored using a prototype.
The worst mess is actually trying to pay off the "debt" in installments by taking on new one. Then running out of time or shifting focus, ending up with double the problem and half the readability.
Those observations pertain specifically to developers who howl about vague technical debts. Those tend to be juniors.
Seniors point out specific issues with specific consequences and lay out specific actions to resolve/mitigate. The term “technical debt” isn’t usually needed in that case.
Technical debt terminology is a fig leaf for “I dont understand and I wont put in the effort to learn”.
The best case is a series of small refactors that split up modules that do too many things and combine modules that always work together and don't benefit from the separation. And most importantly to reduce pieces of code reaching in to the internals of other pieces.
There is no need to do a 2.0, and the number of lines of code will often drop. Though that depends on how much edge case handling code was skipped in the debt version.
146 comments
[ 3.2 ms ] story [ 202 ms ] threadI really like this kind of epistemological analysis on tech terms, specially those that we use all the time and that we think we understand, but mainly for going deeper on a topic and analyze.
"what are the 2 hardest things in technology?"
"Cache invalidation, naming, and off by one errors"
Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept"
However, there are generally accepted meanings of the those terms for the technical debt:
- The "principal" is how many things is wrong with the code. It could be measured in features ("We need to implement unit tests and database layer to clear technical debt") or in time ("it will take 6 FTE-months to clear our technical debt")
- While "interest rate" is rarly used, "interest payment" is common -- this is extra time spent implementing the new feature. One can say: "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"
- Not all debt has fixed term. "revolving debt", like a credit card, has no term at all. Technical debt is like that as well.
(Of course getting the actual values for "pricipal" and "interest payment" is very hard and no two people are likely produce the same estimate for them. But even if don't know the values it does not change the fact the the terms are defined well -- so this is very much a "debt")
As for "not even technical" part: I am going to argue that everything indirectly affects competitiveness, costs, customer satisfaction etc.. A leaking roof will decrease morale, decrease development speed and can even kill the company. Judging by consequences does not really bring anything useful to the table, so if you want to qualify the term, let's use originating action. "Technical debt" if we don't have any tests. "Financial debt" if we took money from the bank. "Organizational debt" if we are not creating the positions we need, and so on...
When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression.
In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are multiple ways of expressing the same.
Quantification of unnecessary complexity can only be done after you know what is necessary and how you express that.
Regardless, technical debt was always clearly a metaphor. I can imagine many other metaphors where one may owe something to oneself, eg, “sleep debt”.
Who cares if it conforms to the definition of the Bank of England?
The project accrues technical debt.
And it owes it to the users.
Because, ultimately, that's who all these FTE hours (the currency borrowed!) are going to.
By taking a shortcut now, you make an implicit promise to the user to rewrite things later (on behalf of the project).
It's the user that suffers if the debt is not repaid (by experiencing bugs, missing features, slow releases, paying for higher headcount to fix bugs, etc).
Shortcuts don't become debt unless the user is affected. If it's stupid and it works, it's not stupid.
And it is the user that will dump your project if that debt is never repaid.
The debt analogy holds water.
Ideally, a dev team delivers feature value at a particular sustainable rate. Think of that as your product team’s ‘income’. Now, if the product team needs a feature early, they can have it if they take out a loan - they can have the feature built without sustainable integration into the codebase - but it will reduce their effective income because future feature delivery will be slowed by the friction of the incurred debt - the interest payments.
Don’t let the product owners make you feel like you have to deal with the burden of debt they took out! They owe you the time to clean up the mess they demanded to get their features faster.
Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.
For example: "Implementing the database layer properly would have taken 5 days; because we took shortcuts (for business reasons) it only took us 3 days. Now we have to implement feature X, and because of our previous shortcut feature X will take 4 days, so 3 + 4 days in total. But if we had implemented the database layer properly in the first place the new feature would have only taken 1 day, so 5 + 1 days in total."
Then in the three-day payment, two are towards principal (that's how much you "borrowed" previously), and one is towards interest.
I didn't read the GP as saying that they were paying down principle. They don't say what the hypothetical feature is, but my assumption was that it's a feature that they could implement without a database layer but that would be faster if they had a database layer. That is, I assumed that even after the 4 days of development for the new feature, they still won't have a db layer – which is why the extra three days is pure "interest".
Even if you don't touch the code at all, it loses its value.
- Developers forget why did they make particular choices, and what were the implications.
- Technologies do age, and there will be maintenance cost for updating that.
This is why it is important to refactor dangerous system deficiencies sooner. If tech debt takes 2 weeks to clean, one can always squeeze that into the plans. If tech debt takes 1 year to clean, it is nigh impossible to persuade the business give that much time.
Technical debt is not corporate debt but it is debt. The metaphor succeeds mostly because it's accurate.
B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at some point and uses this to say "it's not technical because it's business". But it is technical because, well, it is issues with your technology. That you borrowed on your tech stack for business reasons doesn't make it less technical
C) ironically I'm arguing on semantics because I find the title to be semantically wrong. In fact I largely agree with the point of view, tech debt is the result of a strategy, be it that you want speed or low cost. Sometimes it makes sense for the business, and as long as the strategy is conscious and explained, and that we're clear with the consequences, I'm fine with it. In my experience most of the time it's not an assumed strategy and we dont want to deal with the consequences.
It is important to occasionally have arguments to clarify semantics so we maintain the meaningfulness of our language. Otherwise, we lose the ability to communicate.
Some people believe that meaningful communication is unimportant. Those people are wrong.
Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is.
Furthermore, what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.
I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.
Plus, I'm not really sure good practices mattered to them even back then. Academics, whether they're programmers or not, chase different goals and have other incentives.
Like you, I'd love listening to one of them one day (if anyone speaks up). I'm sure there will be a few pearls of wisdom in such a shared experience.
If you have a system that's been modified to handle every edge case encountered in the last decade, and it works, and other people rely on it to do their work, your perspective switches to maintaining the environment the system operates in.
You're looking at automation continuously built around processes that might predate electricity. The interfaces are ingrained into the organization. Other organizations rely on these interfaces and sometimes there are legal responsibilities.
It's a longer-term perspective. Tech debt isn't a crisis, it's an eventuality you try to encapsulate.
I think the key here is indeed that technical debt should not be used as an excuse to write poor code.
But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market.
It "is accepted" that the most of the cost a software comes from the maintenance period - adding bugfixes, new features, and just reading the code.
If the software can be moved from point A where these costs are high (including risk of things getting broken due to complex architecture) to a point B where they are lower, then I could say "technical debt is paid back".
Was the software in point A due to intentional shortcuts, or just because that's how we write software in an unfamiliar territory, is maybe besides the point in gauging the practicality of the term.
The "technical debt" gets anyway accumulated due to the empirical quality of most of software engineering process.
I think this is the most critical thing people should realize - don't take short cuts unless the house is burning down - but do try to explore the problem space fearlessly.
The exploration is due to incomplete understanding of the end user needs. And sometimes you can't really explore that space without delivering something to the user.
But!
I think the exploration phase does not necessarily need to incur technical debt if it's done using prototypes that won't end up in production (yeah yeah like that's ever happened but in theory...).
In this case the deliverable will be just used as a template for the actual product development, with the result that the product may be in a more mature state from the get go, and hence, have less debt from the start.
Should the exploration be done with prototypes or actual vertical slices of production software? I suppose this depends on the situation. Sometimes the problem is actually so hard that you need to deliver a build based on an actual production codebase no matter what.
You can ship good code fast.
Shipping slow is not a guarantee of good code.
I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.
The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that section.
Another example of technical debt is when you write code without tests. You’ll probably finish much faster in the first week or two and then the manual testing will take more and more time. But how often did we see code bases without tests? All the time! And the managers don’t realize how much money they could save by focusing more on quality instead of features.
If you think you‘ll just implement this one thing and then never touch the code again, chances are high you‘ll just hack up the thing and copy paste some code everywhere until it kind of works. This is increasing technical debt, you take out a loan and someone in the future has to pay it back IF they want to make a change. But this is almost always the case, even if you don’t know it now.
My definition of technical debt I wrote down before reading the article: technical debt is the inability to make changes due to not making changes (on a conceptual layer) before.
Author: this has no clearly defined principal and interest, so "owing" is not a word you should use
Someone: ... Never mind
For my part, I use the term sparingly since I find I can easily use it as a catch-all thought-terminating cliche. That doesn’t mean it is useless. Just that it’s bad for me to use it.
People around me know to not let me get away with saying that.
and I say that as someone who doesn't much like analogies or metaphors for most code management issues as I think they often obfuscate the problems more than they illuminate.
It is literally a debt. I dont know what the article is trying to say, it sounds to me like something my boss would say after a 2 hour meeting in a delirious caffeinated state, but thats probably just because I am not familiar with the corporate use of the term "technical debt".
Debt has a negative connotation, where as it’s more like a mortgage.
I always wonder if there’s an equivalent term in manufacturing.
Debt in business is a well-known and appreciated way to get things moving now at some additional cost later.
This applies to both financial debt and technical debt. The difference between those, and hence the name, is how you incur and repay it, not how you make the decision. It's not "business debt" because you can't repay it with "business".
If I were to imagine "business debt", it'd be making decisions now that work well for the moment, but won't work well in the future and will actual retard the business for a while later. You could do it the "right way" now and have fewer customers up front, or you optimize for now and have more customers now, but make it harder to get customers later.
Likewise, financial debt gives you more money right now and costs you more money later. Technical debt gets technical stuff working right now, but takes more time from your tech team later when you need things to be different.
I've only ever seen these terms used in programming contexts
But the result is just that people outside technology think technology is clueless and "they have debt, whatever that means".
"We have technical debt to repay" = bad
"We outgrew the choices we made that allowed us to grow fast, and need to refresh our product to sustain the growth rate" = actually means what we want to say
Makes it clear that prioritizing new features will come at the expense of growth. Which is ultimately what the stakeholders really care about.
Why do we create encapsulated build setups if everyone from the team knows how it install it on their machines anyway?
Why do we waste time on writing documentation?
And above all: if during a three-day hackathon we can create a game, why does it take months or years to create a publishable one?
getting it to walmart is where the chefs get bored and turn one amazing night into years of backlog refinement
It rarely costs less to delay tech work. It often costs more. The "moral force" of the debt analogy is strong.
Tends to happen at the worst of times when you're least prepared.
Spoiler, we never have time.
The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt"
In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our business strategy all along.
Software is very different to building the millennium tower - that's designed once, and when built won't be expected to substantially change or grow (at least from a structural perspective, you will change the interior). Building a skyscraper can take 5 years to complete, and when it's built it looks like the design from 5 years ago (with all the same load assumptions). With software the design is expected to change throughout the lifecycle, and should adapt to customer demand and scaling requirements, and you can't wait 5 years for perfect when 'good enough' will do and get you live.
For social media kind of traffic it became inadequate at some point and the debt had to be paid (and thanks to success was easy to pay).
To me a smart use of technical debt.
Certain qualities or features like horizontal scalability and security can be relatively inexpensive to design in at the beginning and immensely expensive to try to tack on later once a system is already in wide use.
Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle.
Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot of buildings have little spaces reconverted to closets just because there was leftover space there. That's technical debt, you know the "best approach" (according to waterfall engineering) would be to find out how things will work and then build it, but you'd rather write "IOU" on that section and move on to the important bits. You can then solve the kinks with plasterboard.
The best example of technical debt is code that doesn't scale. You know you should write your code to support 1M users, but you currently have ~100 users. Instead of spending a month serving 990k users you don't have, I would say it's good engineering to solve the problem for say 10k users if that means you'll spend a week, and have the rest of the time to solve other more pressing concerns.
I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.
You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.
The problem is rather that the technical debt is often not repaid.
That's not a technical choice since the person writing code wasn't aware of the options, so it's a business choice. How good of a business choice is it, though?
We all know at some level that a well-intentioned but inexperienced engineer can make a decision in an afternoon that will take weeks or years to clean up. I often see junior engineers spend several days over-engineering something that a senior engineer would have done simpler and better in a fraction of the time. I don't think it's a given that junior engineers provide better return on investment early on that a senior engineer.
Getting some worthwhile feedback and advice from a seasoned engineer doesn't need to cost a fortune in up-front cash, and personally I think it'll pay for itself. You either compensate them with stock or hire them as a temporary or part time consultant.
> Cunningham: I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.
Technical debt is not about technology, but about better understanding of functional domain, after which you should refactor your current implementation to better reflect reality in the sense that there is a more clean abstraction and accompanied code.
No abstraction will save you from this.
If it were this easy you wouldn't see so many people taking on so many unnecessary debts. Technical or otherwise.
Chiefly the answer to the question "how will this amount change if the interest rates go from effectively zero to 6%, which is the 30-year average?" is not straightforward.
This really is NOT how you start an article. You only come across as needlessly assertive and arrogant.
> Nobody explained technical debt; we assumed it was a fundamental property of the work.
Total BS. Literally every manager I ever addressed in a sentence where "technical debt" was mentioned did question what exactly it is and why do we need to address and "repay" it. Where is the author of the article living? Not with us the programmers here on the ground, that's for sure.
> Now, one major concern in academia is rigor.
Ah, so now it's about academia and its definition. I'll cut him a deal. Bring your academics to my former customers and see if they can override management's idea of a technical debt. Succeed 5 times and then I'll bow to you and accept your definition. Until then you're just an annoyance like that guy on parties who is always going around telling people "well ACTUALLY you are using the wrong term".
Doesn't matter what the dictionary says, people. It matters what most of the people think a word means. It matters what most of the people do when faced with the word. Why is this so hard to accept for many?
--
No, I haven't read the entire article. It smells of intellectual elitism and arrogance a mile away. The author must work on his tone.
Technical debt, whatever your definition of it is, is still a natural property of tight schedules. That's it. We can all go home now.
I wouldn't expect an academic to understand realities of schedules and budgets though.
My initial thought was that, as academics, they were going to be aloof and out of touch. However, as a boots on the ground dev who has worked from start up through multi-thousand employee public company, and who has held leadership roles, I agree with the article. Maybe if you read it, you would too.
I've given very compelling arguments to address tech debt that made a room of 20+ people in management smile and nod approvingly. Yet higher leadership still overruled me (and them).
If not, I am not convinced the article has anything to offer me in particular.
TD is any code/architecture aspect to which PMNOPML applies.
As with gravity, it's going to suck whether one fancies the label or not.
1. Is "technical debt" debt: If it walks like a duck...
Not all debt is in the form of retail loans. Leaving a "IOU" note where someones lunch was, is a form of debt (a very dangerous one). Good luck trying to find out your interest rate in advance.
2. Is "technical debt" technical: If we follow the author's logic, I guess now financial debt is not financial. Financial debt will also affect:
That's the point altogether, "technical debt" behaves in similar ways to financial debt.In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time.
Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equally problematic.
In the worst case, you have a combination of ignorance and best-practice-hysteria that gets applied to actually-fit-for-purpose code. Then the 200 lines of performant and correct code that takes two hours to fully understand, gets turned into 2000 lines of deeply nested class hierarchies mixed with immutable FP-wank that takes several days to get a grasp of and both fails to handle real-world data (“not in the specification!”) and tanks system performance (“premature optimizations!”).
It's called second system effect and it's relatively easy to avoid by methodically documenting original and mercilessly avoiding adding features.
And this includes design features that are not immediately shown to save a lot of time and code. Every such feature needs an advocate and also a prosecutor, and alternatives have to be briefly explored using a prototype.
The worst mess is actually trying to pay off the "debt" in installments by taking on new one. Then running out of time or shifting focus, ending up with double the problem and half the readability.
Seniors point out specific issues with specific consequences and lay out specific actions to resolve/mitigate. The term “technical debt” isn’t usually needed in that case.
Technical debt terminology is a fig leaf for “I dont understand and I wont put in the effort to learn”.
There is no need to do a 2.0, and the number of lines of code will often drop. Though that depends on how much edge case handling code was skipped in the debt version.