10 ms·

Technical Debt Doesn’t Exist

71 points by user5994461 6y ago

ZiiS 6y ago
Whilst I am sure Debt exists in classic software it is endemic in SaaS. If the truck is travelling at highway speed and you cannot afford to pull over; changing the break pads can indeed cost considerably more then building a new truck.
ekvilibrist 6y ago
So there's no bad code, no poorly designed systems? Only "maintenance"?
- always_left 6y ago
  Going to cite this article if I have a bad performance review.
- AmericanChopper 6y ago
  Taking a useful analogy, or conventional piece of wisdom and contriving it into something meaningless is an excellent strategy for premium thoughtleader blog writing. Even the people who think your ideas are dumb will still click.
- preordained 6y ago
  If the code was initially a net positive (i.e. provided a feature users wanted/needed, etc.), then in a way, yes. It might be bad in the abstract in the way patching something with bubblegum is, but if it works at the time--it works. I think the only way to argue it was wholesale bad is that it immediately and objectively sank future progress (like a fatal wound of sorts). If it made things a hassle going forward, you'd have to argue that it was so much of a hassle that it actually receded things back into a negative. Most companies rarely experience the debt that stops forward progress cold or can prove they'd be making X times more progress if wasn't for such and such debt. That said, if you could do things in such a way that yields the desired result and causes less (there is always some, and never little) maintenance, that's ideal. The thing is, everyone is trying to code from that place. The only ones who aren't are those who can't (they really are incompetent) or those who have given into utter malaise or malice.
xupybd 6y ago
It does exist in the form of libraries and language versions that slowly get dropped from modern eco systems. Each dependency adds a little more debt.
ilikerashers 6y ago
Having done building work in various guises over the years, I've seen is interesting patterns analogous to software development. Every builder comes in and says the previous guy didn't do it properly, used the wrong materials and overcharged. Every software project I've been on, someone always comes in and says there's tons of technical debt, we're using the wrong language and the other developers are poor. There's probably some truth in both statements but it takes experience and knowledge to take things with a pinch of salt.
- xupybd 6y ago
  Did you make the switch from software to building? If so why? Edit. This is genuine curiosity. I've made a slide out of software development into a more hands on role. I've found it rewarding.
  - ilikerashers 6y ago
    I just have building projects in a couple of rental properties and my own. Good luck in your building career, it sounds like the "Office Space" story!
- smt88 6y ago
  > Every software project I've been on, someone always comes in and says there's tons of technical debt They say that because it's true. Every project has a lot of technical debt. Good technical management should understand the problems caused by the debt and prioritize it accordingly. Bad technical management will devote no time to technical debt, and it will grow exponentially.
ggm 6y ago
The principle force of the analogy is the compound interest equivalent cost of delayed update. Jumping over versions can acquire more bugs than you can handle and the cost of remediation en masse under time duress is not the same amortised time as the per increment bugfixing across the versions I have experienced this and I also work with people who deny it. It's complicated.
mrphoebs 6y ago
The distinction between maintenance and Tech Debt comes down to whether the choice for an imperfect or expedient way of solving the problem was made consciously. You incur Tech Debt consciously to deliver value in the short term at the cost of not being able to sustainably deliver that value as parameters change. Maintenance on the other hand is stewardship of a system as both the system(entropic decay) and it's environment constantly change.
- megous 6y ago
  Dunno. You can make conscious choices that will affect the maintenance burden in the future. So it's all blurry.
- spookylukey 6y ago
  I found Martin Fowler's "Technical Debt Quadrant" helpful on this - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html https://martinfowler.com/bliki/TechnicalDebtQuadrant.html . He argues you can have deliberate and inadvertent debt, both of which can be wise or unwise - the debt metaphor still works.
alxlaz 6y ago
I sympathize with the author's take that our industry is way too trigger-happy and willing to throw away perfectly working code, but none of this: > Python 3 changed all the string handling, have to make adjustments. The build is too slow, should make it faster. Security vulnerability found in one library, time to update libraries. is what (most?) people mean by technical debt. If the build is just slow, but can be improved, that's not technical debt. Technical debt is when the build system is actually a bash script that was written ten years ago because none of the developers wanted to waste time on a proper makefile, and none of the interns knew make (or cmake, or ant, or whatever), and now just adding a new source file takes three hours. (Edit: oh, or my favourite example, how could I forget this? I've worked on a very large (MLoC) codebase that used autotools as a build system. Unfortunately, at some point, someone didn't want to learn m4 -- totally understandable -- and committed a manually-mangled configure script and a bunch of generated makefiles... ...and from that point, autotools were eschewed completely, and the configure script, and the generated makefiles, had mangled by hand each time something was required. Adding a new module to that program took 2-3 days of grepping and hunting through a bunch of files, just to make sure you didn't miss anything. That's more than enough time to learn the basics of how to use autotools. Multiply it by several hundred modules and weep.) If a security vulnerability is found in a library, and that's solved with a library update, that's not technical debt. Technical debt is when message signing is done via MD5 hashes produced by a slightly buggy in-house implementation. You got to ship on time, but not by shipping a functional product -- that's a bug, and it still has to be fixed at some point. If some stuff is single-threaded and slow, but easy enough to parallelize so that it's faster, that's not technical debt. Technical debt is when there's a single, global object containing absolutely all application state, and splitting an extra thread to do some computation in the background requires four weeks of extra manual testing just to be sure you didn't introduce another race condition. (Edit: unfortunately, nope, none of the examples above were invented. I had the pleasure of working on a codebase where adding a new thread literally required written approval from the product manager because of the extra testing it required. Calling that "maintenance" is much like calling a bridge collapse a "vertical position readjustment" -- it gleefully ignores the fact that it was readjusted downwards, through gravity, possibly involving mass casualties, and had to be rebuilt). Some maintenance work is legitimate and is just the result of normal software progress. But some maintenance work is entirely self-inflicted. Ignoring that is just an excuse for the kind of "first we do git push, then we think about it" crunch mentality that lots of companies encourage, for reasons that have absolutely nothing to do with either productivity or technical excellence.
jjn2009 6y ago
If someone is knowingly building something that wont scale is that not an accumulation of future work? I think the key point about technical debt is that units of work are not all equal in long term outcomes.
jpswade 6y ago
Technical debt is just business debt, it’s risk to the business if people don’t understand it or it’s hard to maintain. Technical debt is a terrible term because it implies it’s just a technical problem, but it’s a business decision.
- juniper_strong 6y ago
  It's a terrible term because the technical people think they are talking to the business people in their terms, but when the business side of the operation hears the term technical debt, they ask some questions and what they hear is that they are issuing non-recourse debt. What the technical side of the operation wants to say is "We're making short term decision that are going to hurt us in the long term", and what the business side of the operation hears is "This is free money".
cjfd 6y ago
I completely get where this person is coming from. The distinction between maintenance and producing new features on one side and paying down technical is so strange. It does not make very much sense to start working on a piece of the code that is hardly every touched and that has been working for years to improve it. What one should be doing instead is to make sure that the work one is doing for the purpose of maintenance and creating new features leaves the code base in a better state than it was found in. If one does that it becomes mostly unnecessary to talk about technical debt. I do think technical debt does exist, though. Sometimes the changes that one wants to do are a bit too big to do right now and one should make a plan to get them done eventually and in small pieces wherever possible. This is called having architectural goals. One should try to be in this situation as little as possible, though.
tsechin 6y ago
Calling tech debt maintenance seems a little odd. I've always understood tech debt to be the shortcuts we take along the way to ship fast(er). A global variable here, a hardcoded constant there, that copy-pasted-slightly-modified function instead of adding a parameter. Fixing those things seems qualitatively different from the maintenance examples.
jankotek 6y ago
> To make another analogy, when you bring your car to the mechanic to replace breaks after 80 000 kilometers, he doesn't proceed to warn that the previous mechanics has left debt'ed break pads all over the place and to question the person's qualifications. Good mechanic will refuse to touch your car. If breaks would fail after her fix, she might be liable. Same apply to coders. If your code is bad, it will be very difficult to find good developer to fix it.
wokwokwok 6y ago
Technical debt isn’t an arbitrary thing; it’s a metaphor to try to explain doing maintenance to non technical folk. The explanation goes like this: If you have no debt, you can borrow money. If you have a bit of debt, you can borrow money, but you have to make regular repayments of maintenance to service that debt. ...but when you have a lot of debt, lenders are cautious about lending you money. Will you pay it back? Why didn’t you pay back any of your other debts? Can you afford the repayments? The metaphor isn’t perfect, but the point being made is that maintenance is the repayments on technical debt; if ignore it, at some point you are going to end up spending all your developer hours on maintenance, and your throughput for features will grind to a halt. You “repay” the technical debt by fixing stuff that causes problems, not by randomly rewriting it because you can’t be bothered reading the existing source code. It’s not maintenance. That’s a different thing; that’s making changes. Technical debt is more like a metric of how prone to failure /what feature velocity your software is / has. Sure, the metaphor falls over; you can just keep slapping broken features and other crap on top of either other indefinitely if you dont care if your existing features work or not... but, that’s a different issue.
- xixixao 6y ago
  The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.
  - zuppy 6y ago
    > is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc
amelius 6y ago
Is "technical debt" a term used more by business people/managers or by developers?
- rablackburn 6y ago
  Personally I (a developer) use it most as a metaphor for business people explaining why we need to schedule time in-sprint for work that isn't explicitly tied to a new feature. We have debt, we need to service it. Repayments come in the form of developer time. If our debt is well-serviced it enables us to keep up a nice quick pace of feature development. If a feature is politically important and our tech-debt is under control we can fast-track its implementation knowing that we'll have time to polish it up later and it isn't likely to break too much. If our debt is too high we can't borrow anymore. Sorry, that super important feature that the board wants by end of sprint simply can't be done. We're at our credit limit and if we try and borrow more to get that done we'll go bankrupt (the product crashes and burns). All of this is the language of business
choeger 6y ago
Technical debt is not maintenance. Except for a very radical perspective: "So you used python2 in 2008 to start your project? Well you obviously knew the language would not last forever, you should have chosen ANSI C99 instead." This argument can be made for any dependency and it contains a grain of truth, but generally it is just too extreme.
prashnts 6y ago
No it does. You make a point before bikeshedding.
jasode 6y ago
>Software do not have a technical debt problem, software simply requires maintenance. [...] There is no such thing as technical debt. There is work to do, that we can agree on, but it’s not debt payment. The "technical debt" doesn't have a 100% universal agreement on what it means and apparently the author has only been exposed to one variation of it and that's what he's rebutting. Another type of "debt" is caused by programmers writing bad/clunky code (often deliberately) to quickly solve a problem. The wikipedia article mostly talks about this definition of "debt"[1]. The programmers know the bad code will create "debt" that makes future maintenance harder. Example of this tension would be 2 different approaches to adding a feature or bug fix: - (1) study the code base carefully -- maybe for hours or days -- and then write the properly architected code that makes future changes/extensions easy. E.g. expend the extra brainpower to see if the multiple edge cases or logic spread across files can be unified or simplified. ... or ... - (2) quickly find the points in source code that seem "obvious" to modify just change it -- sometimes copy-pasting code and duplicating logic if if/then/else or switch/case statements in multiple files. Yes, now the immediate issue is "fixed" but you've simultaneously created "debt" down the road. [1] https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt first sentence: Technical debt (also known as design debt[1] or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]
gjulianm 6y ago
Maintentance is not technical debt, and confusing both terms is weird. While there are multiple definitions, I'd say maintentance is the work of making adjustments to keep the software in a working state, say supporting new operating systems, fixing bugs, updating to minor versions of libraries... Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present. And every programmer does this, consciously or unconsciously. Say hard-coding some parameters in functions instead of creating user-defined options because it's easier, or writing a specific class instead of an abstract one that can be later extended, or writing a hack instead of refactoring so that new changes fit properly. Of course, it's difficult to predict the future and some technical debt is never repaid. But it's important to make a distinction and to have in mind the technical debt in your project and when it's worth it to remove it.
- mytailorisrich 6y ago
  Spot on comment. I'd add that there is also a principle of not trying to predict the future and make design over-general and over-flexible 'just in case', but rather to have the simplest design that fits current requirements (though of course it should be clean and follow good practice). The may lead to technical debt in the future but it may not. The idea being not to spend until you have to. Now, a fudge now to save time should only be done under tight schedule with a plan to fix it later... In an ideal world. I think this is the case that really fits the analogy of borrowing/debt. Overall, technical debt is unavoidable in a ever changing, unpredictable environment
  - user5994461 6y ago
    I agree that further work is unavoidable in an ever changing environment. Software is built over time with the environment constantly shifting under it, it's a cycle to maintain and extend (constant changes if you will). That's the crux of why technical debt doesn't exist, or is not a receivable term. If it were debt there should be a way not to take it, but there isn't. Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable. One solution to not have debt may be to not write anything, that's not receivable because then there would no product and no company. The other implication is that there may be a perfect state to reach with no debt, but that's not the case, realistically it's not possible to start from code that's perfect and bug free and supports every (future) feature in the universe.
bencollier49 6y ago
It feels to me as though this argument misses the point. -- Technical debt is time that you have borrowed from the future. -- That makes perfectly good sense if you need a simple, working system, quickly. But if you plan on extending it, then the workarounds and shortcuts that you took will need to be replaced, slowing you down in future. Concrete classes where abstractions will be needed in future, hard-coded values, all that stuff. The debt will have to be repaid.
cloudhead 6y ago
Complete nonsense..
pdimitar 6y ago
Pretty low-quality flaming post. Basically "battle of the word definitions". Refactoring is observably the best way to get to know someone's code. Refactoring doesn't have to actually change behaviour; in fact, the word itself means "improving the code without changing its behaviour". Not seeing any value in this post outside of "I disagree with some words, let's use others".
- Cthulhu_ 6y ago
  This is what I've caught myself doing; instead of reading and trying to understand the code, I scan it and start "fixing" it to make it my own. Writing and changing code is a lot less boring than just reading it. Focusing on details (formatting, function naming, ordering, files) seems to be a lot more "gratifying" than trying to grasp the bigger picture. I guess this is why I'll never become a senior developer / architect. Mind you, atm I don't have anyone else working on the same codebase either so it's all me.
  - pdimitar 6y ago
    What's a senior developer? I had zero problems grasping a lot of bigger pictures but since I didn't care much about political and office drama I never was dubbed "senior" while working in offices. At one point I decided for myself that I am senior by the virtue of being able to quickly understand what's happening in a codebase and where the real value-add lies, plus the ability to integrate it into the bigger ecosystem of deployments that the company practices. And having a good general culture. So don't you care about "senior". :) As for the topic -- harmless refactoring is indeed the way to get to know code. This has been said by people like Martin Fowler and Kent Beck so it's not exactly baseless and isn't easily refutable by a flaming post like the OP.
firstbabylonian 6y ago
I agree with this. 'Technical debt' always exists in the heads of the engineers: the rest of the organisation can't see it. It's an invisible problem, imagined by the engineers, and not always in touch with the practical long-term reality. Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. Whereas saying 'technical debt' is like delivering a dramatically vague House MD diagnosis. If you must, call it what it is – Maintenance – and let's move on.
- galoisgirl 6y ago
  If it exists only in the heads of the engineers, then it's not technical debt. Don't get me wrong, there are problems that mainly exist "in the heads of the engineers". Many of them want to refactor code or migrate to a newer framework or re-write for the latest buzzwords. But that's not technical debt.
- ggreer 6y ago
  > Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. Yes software is a tool, but unlike physical tools, it does not wear out. Running the same code many times won't cause it to slowly degrade. What does happen with software is that as you adapt it to particular roles, if you're not careful you can make it very hard to re-adapt to new roles. A "new role" doesn't necessarily mean user-facing features. It can be as simple as running on Ubuntu instead of running on RHEL. Or it can involve using a newer (and incompatible) version of some library. It might even be as daunting as porting the software to a new language (eg: from JavaScript to TypeScript). The common analogy used to illustrate this is that of a car. If you have a typical passenger car and you need to compete in a demolition derby, you can modify that car to be a good demolition derby car. But if you're then asked to modify that car to win a track race, you'll have an easier time starting with a new unmodified passenger car than modifying your demolition derby car.
- gjulianm 6y ago
  > Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. In that context, maintenance is fixing your screwdriver. Technical debt is having a fixed-head screwdriver instead of another with swappable heads: it might be ok for you if you mainly use that one, but if you're constantly needing to buy new screwdrivers and carry them, it's extra money and work. And the same as technical debt, you might decide to buy first a fixed -head screwdriver because you're not certain about your future needs and it's just cheaper and easier, and then switch to a swappable head when you are certain you need it.
OldHand2018 6y ago
Where I work, "technical debt" is a term used by the project management folks whenever they are looking for justification for forcing developers to do something that everyone knows is a bad idea. No worries, we'll come back to it when we have more time (we never have more time).
- Viliam1234 6y ago
  > No worries, we'll come back to it when we have more time (we never have more time). There are only two priorities: priority one, and priority "we will actually never do this, because always something else will be priority one". But of course, if it makes the engineers happy, we can put "fixing technical debt" in Jira, and assign it any priority between 2 and 99.
grafelic 6y ago
To me (from an Ops perspective), technical debt is when people who have come before you implemented a setup that is broken at a deep level. A setup which can only be fixed by a complete re-implementation. No amount of maintenance will suffice.
ChrisMarshallNY 6y ago
> This is meant literally. Reading existing code is difficult -more difficult than writing code- thus it is a genuine take from the developer that throwing everything away and starting over from scratch is “easier” than continuing on the existing. [Ergo this is flawed for non-small projects because the new development will never catch up with the existing during the tenure of the developer(s).] I tend to work alone, so the poor schlub that needs to go in and maintain the code is usually Yours Truly. That’s a big reason that I am pretty obsessed with heavily-documented code. I eat my own dog food. It is quite painful to review undocumented codebases; even (especially) really well-written code. I write in Swift, and it’s entirely possible for an experienced Swift programmer to write highly efficient code that is almost completely inscrutable. Not sure I’d necessarily call that “technical debt,” but it’s a real issue. I’ve learned to use naive coding (in reality, highly efficient code often doesn’t buy squat), and a lot of “this is why I did this” commenting, along with long, descriptive entity names[0]; assuming that it’s my goal for my code to be maintained by others, and to not have them constantly pinging me with questions. I will say that the (fairly ambitious) projects I’ve done that have grown into large community efforts, have resulted in very, very few questions about the code. It seems that understanding the code I write, isn’t an issue, for most people. I write code for myself, and that seems to make others happy. [0] https://medium.com/chrismarshallny/leaving-a-legacy-1c2ddb0c8014 https://medium.com/chrismarshallny/leaving-a-legacy-1c2ddb0c...
sixstringtheory 6y ago
Technical debt is not maintenance. Technical debt is the additional maintenance for which you create a need when, presented with multiple options to implement a thing, you take the quickest and dirtiest one. It compounds the more you make decisions like that, just as compounding interest and capitalization create ever higher amounts of monetary debt. Also, I found their self-referenced article on how Windows required more work than the pyramids, using man hours as a metric, simply absurd. This strikes me as a mythical man month type fallacy but can’t quite put my finger on it.
websitescenes 6y ago
Technical debt != maintenance.. Maintenance is just maintenance. Technical debt is having to jump through arbitrary hoops to satisfy a code base or piece of technology instead of being able to directly address the problem at hand. With that said, I do agree that all code has some degree of technical debt but that can be limited by good design.
karmakaze 6y ago
This is all just words and redefinitions, how you choose to slice and label things. Here's the useless reframing: > Software do not have a technical debt problem, software simply requires maintenance. Despite the words used, tech debt does exist. This article doesn't do much to make the task of maintaining software any better. It lumps it all together. Tech debt, created accidentally or purposefully can be reduced with specific forms of maintenance which makes further changes easier and reducing future maintenance efforts.
rdiddly 6y ago
I like the debt metaphor, especially because of 1) interest, which costs more the more debt there is and the longer you carry it, and 2) the fact that sometimes it's smarter to borrow than to be debt free.
IceDane 6y ago
What a vapid, shallow and uninteresting article. Congratulations, you just gave technical debt another name. That doesn't mean it doesn't exist. Maybe you should try reading up on the subject matter next time before writing a blog post so you don't end up rediscovering fire again.
Fire-Dragon-DoL 6y ago
I think the point might be the term? I read somewhere a suggested alternative: product debt. The technical side is the one that loaned the time in terms if shortcut. Paying it back has always a steeper cost. Not only that, it also compounds.

71 points by user5994461 6y ago

ZiiS 6y ago

Whilst I am sure Debt exists in classic software it is endemic in SaaS. If the truck is travelling at highway speed and you cannot afford to pull over; changing the break pads can indeed cost considerably more then building a new truck.

ekvilibrist 6y ago

So there's no bad code, no poorly designed systems? Only "maintenance"?

always_left 6y ago
Going to cite this article if I have a bad performance review.
AmericanChopper 6y ago
Taking a useful analogy, or conventional piece of wisdom and contriving it into something meaningless is an excellent strategy for premium thoughtleader blog writing. Even the people who think your ideas are dumb will still click.
preordained 6y ago
If the code was initially a net positive (i.e. provided a feature users wanted/needed, etc.), then in a way, yes. It might be bad in the abstract in the way patching something with bubblegum is, but if it works at the time--it works. I think the only way to argue it was wholesale bad is that it immediately and objectively sank future progress (like a fatal wound of sorts). If it made things a hassle going forward, you'd have to argue that it was so much of a hassle that it actually receded things back into a negative. Most companies rarely experience the debt that stops forward progress cold or can prove they'd be making X times more progress if wasn't for such and such debt. That said, if you could do things in such a way that yields the desired result and causes less (there is always some, and never little) maintenance, that's ideal. The thing is, everyone is trying to code from that place. The only ones who aren't are those who can't (they really are incompetent) or those who have given into utter malaise or malice.

xupybd 6y ago

It does exist in the form of libraries and language versions that slowly get dropped from modern eco systems. Each dependency adds a little more debt.

ilikerashers 6y ago

Having done building work in various guises over the years, I've seen is interesting patterns analogous to software development. Every builder comes in and says the previous guy didn't do it properly, used the wrong materials and overcharged. Every software project I've been on, someone always comes in and says there's tons of technical debt, we're using the wrong language and the other developers are poor. There's probably some truth in both statements but it takes experience and knowledge to take things with a pinch of salt.

xupybd 6y ago
Did you make the switch from software to building? If so why? Edit. This is genuine curiosity. I've made a slide out of software development into a more hands on role. I've found it rewarding.
- ilikerashers 6y ago
  I just have building projects in a couple of rental properties and my own. Good luck in your building career, it sounds like the "Office Space" story!
smt88 6y ago
> Every software project I've been on, someone always comes in and says there's tons of technical debt They say that because it's true. Every project has a lot of technical debt. Good technical management should understand the problems caused by the debt and prioritize it accordingly. Bad technical management will devote no time to technical debt, and it will grow exponentially.

ggm 6y ago

The principle force of the analogy is the compound interest equivalent cost of delayed update. Jumping over versions can acquire more bugs than you can handle and the cost of remediation en masse under time duress is not the same amortised time as the per increment bugfixing across the versions I have experienced this and I also work with people who deny it. It's complicated.

mrphoebs 6y ago

The distinction between maintenance and Tech Debt comes down to whether the choice for an imperfect or expedient way of solving the problem was made consciously. You incur Tech Debt consciously to deliver value in the short term at the cost of not being able to sustainably deliver that value as parameters change. Maintenance on the other hand is stewardship of a system as both the system(entropic decay) and it's environment constantly change.

megous 6y ago
Dunno. You can make conscious choices that will affect the maintenance burden in the future. So it's all blurry.
spookylukey 6y ago
I found Martin Fowler's "Technical Debt Quadrant" helpful on this - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html https://martinfowler.com/bliki/TechnicalDebtQuadrant.html . He argues you can have deliberate and inadvertent debt, both of which can be wise or unwise - the debt metaphor still works.

alxlaz 6y ago

I sympathize with the author's take that our industry is way too trigger-happy and willing to throw away perfectly working code, but none of this: > Python 3 changed all the string handling, have to make adjustments. The build is too slow, should make it faster. Security vulnerability found in one library, time to update libraries. is what (most?) people mean by technical debt. If the build is just slow, but can be improved, that's not technical debt. Technical debt is when the build system is actually a bash script that was written ten years ago because none of the developers wanted to waste time on a proper makefile, and none of the interns knew make (or cmake, or ant, or whatever), and now just adding a new source file takes three hours. (Edit: oh, or my favourite example, how could I forget this? I've worked on a very large (MLoC) codebase that used autotools as a build system. Unfortunately, at some point, someone didn't want to learn m4 -- totally understandable -- and committed a manually-mangled configure script and a bunch of generated makefiles... ...and from that point, autotools were eschewed completely, and the configure script, and the generated makefiles, had mangled by hand each time something was required. Adding a new module to that program took 2-3 days of grepping and hunting through a bunch of files, just to make sure you didn't miss anything. That's more than enough time to learn the basics of how to use autotools. Multiply it by several hundred modules and weep.) If a security vulnerability is found in a library, and that's solved with a library update, that's not technical debt. Technical debt is when message signing is done via MD5 hashes produced by a slightly buggy in-house implementation. You got to ship on time, but not by shipping a functional product -- that's a bug, and it still has to be fixed at some point. If some stuff is single-threaded and slow, but easy enough to parallelize so that it's faster, that's not technical debt. Technical debt is when there's a single, global object containing absolutely all application state, and splitting an extra thread to do some computation in the background requires four weeks of extra manual testing just to be sure you didn't introduce another race condition. (Edit: unfortunately, nope, none of the examples above were invented. I had the pleasure of working on a codebase where adding a new thread literally required written approval from the product manager because of the extra testing it required. Calling that "maintenance" is much like calling a bridge collapse a "vertical position readjustment" -- it gleefully ignores the fact that it was readjusted downwards, through gravity, possibly involving mass casualties, and had to be rebuilt). Some maintenance work is legitimate and is just the result of normal software progress. But some maintenance work is entirely self-inflicted. Ignoring that is just an excuse for the kind of "first we do git push, then we think about it" crunch mentality that lots of companies encourage, for reasons that have absolutely nothing to do with either productivity or technical excellence.

jjn2009 6y ago

If someone is knowingly building something that wont scale is that not an accumulation of future work? I think the key point about technical debt is that units of work are not all equal in long term outcomes.

jpswade 6y ago

Technical debt is just business debt, it’s risk to the business if people don’t understand it or it’s hard to maintain. Technical debt is a terrible term because it implies it’s just a technical problem, but it’s a business decision.

juniper_strong 6y ago
It's a terrible term because the technical people think they are talking to the business people in their terms, but when the business side of the operation hears the term technical debt, they ask some questions and what they hear is that they are issuing non-recourse debt. What the technical side of the operation wants to say is "We're making short term decision that are going to hurt us in the long term", and what the business side of the operation hears is "This is free money".

cjfd 6y ago

I completely get where this person is coming from. The distinction between maintenance and producing new features on one side and paying down technical is so strange. It does not make very much sense to start working on a piece of the code that is hardly every touched and that has been working for years to improve it. What one should be doing instead is to make sure that the work one is doing for the purpose of maintenance and creating new features leaves the code base in a better state than it was found in. If one does that it becomes mostly unnecessary to talk about technical debt. I do think technical debt does exist, though. Sometimes the changes that one wants to do are a bit too big to do right now and one should make a plan to get them done eventually and in small pieces wherever possible. This is called having architectural goals. One should try to be in this situation as little as possible, though.

tsechin 6y ago

Calling tech debt maintenance seems a little odd. I've always understood tech debt to be the shortcuts we take along the way to ship fast(er). A global variable here, a hardcoded constant there, that copy-pasted-slightly-modified function instead of adding a parameter. Fixing those things seems qualitatively different from the maintenance examples.

jankotek 6y ago

> To make another analogy, when you bring your car to the mechanic to replace breaks after 80 000 kilometers, he doesn't proceed to warn that the previous mechanics has left debt'ed break pads all over the place and to question the person's qualifications. Good mechanic will refuse to touch your car. If breaks would fail after her fix, she might be liable. Same apply to coders. If your code is bad, it will be very difficult to find good developer to fix it.

wokwokwok 6y ago

Technical debt isn’t an arbitrary thing; it’s a metaphor to try to explain doing maintenance to non technical folk. The explanation goes like this: If you have no debt, you can borrow money. If you have a bit of debt, you can borrow money, but you have to make regular repayments of maintenance to service that debt. ...but when you have a lot of debt, lenders are cautious about lending you money. Will you pay it back? Why didn’t you pay back any of your other debts? Can you afford the repayments? The metaphor isn’t perfect, but the point being made is that maintenance is the repayments on technical debt; if ignore it, at some point you are going to end up spending all your developer hours on maintenance, and your throughput for features will grind to a halt. You “repay” the technical debt by fixing stuff that causes problems, not by randomly rewriting it because you can’t be bothered reading the existing source code. It’s not maintenance. That’s a different thing; that’s making changes. Technical debt is more like a metric of how prone to failure /what feature velocity your software is / has. Sure, the metaphor falls over; you can just keep slapping broken features and other crap on top of either other indefinitely if you dont care if your existing features work or not... but, that’s a different issue.

xixixao 6y ago
The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.
- zuppy 6y ago
  > is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc

amelius 6y ago

Is "technical debt" a term used more by business people/managers or by developers?

rablackburn 6y ago
Personally I (a developer) use it most as a metaphor for business people explaining why we need to schedule time in-sprint for work that isn't explicitly tied to a new feature. We have debt, we need to service it. Repayments come in the form of developer time. If our debt is well-serviced it enables us to keep up a nice quick pace of feature development. If a feature is politically important and our tech-debt is under control we can fast-track its implementation knowing that we'll have time to polish it up later and it isn't likely to break too much. If our debt is too high we can't borrow anymore. Sorry, that super important feature that the board wants by end of sprint simply can't be done. We're at our credit limit and if we try and borrow more to get that done we'll go bankrupt (the product crashes and burns). All of this is the language of business

choeger 6y ago

Technical debt is not maintenance. Except for a very radical perspective: "So you used python2 in 2008 to start your project? Well you obviously knew the language would not last forever, you should have chosen ANSI C99 instead." This argument can be made for any dependency and it contains a grain of truth, but generally it is just too extreme.

prashnts 6y ago

No it does. You make a point before bikeshedding.

jasode 6y ago

>Software do not have a technical debt problem, software simply requires maintenance. [...] There is no such thing as technical debt. There is work to do, that we can agree on, but it’s not debt payment. The "technical debt" doesn't have a 100% universal agreement on what it means and apparently the author has only been exposed to one variation of it and that's what he's rebutting. Another type of "debt" is caused by programmers writing bad/clunky code (often deliberately) to quickly solve a problem. The wikipedia article mostly talks about this definition of "debt"[1]. The programmers know the bad code will create "debt" that makes future maintenance harder. Example of this tension would be 2 different approaches to adding a feature or bug fix: - (1) study the code base carefully -- maybe for hours or days -- and then write the properly architected code that makes future changes/extensions easy. E.g. expend the extra brainpower to see if the multiple edge cases or logic spread across files can be unified or simplified. ... or ... - (2) quickly find the points in source code that seem "obvious" to modify just change it -- sometimes copy-pasting code and duplicating logic if if/then/else or switch/case statements in multiple files. Yes, now the immediate issue is "fixed" but you've simultaneously created "debt" down the road. [1] https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt first sentence: Technical debt (also known as design debt[1] or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]

gjulianm 6y ago

Maintentance is not technical debt, and confusing both terms is weird. While there are multiple definitions, I'd say maintentance is the work of making adjustments to keep the software in a working state, say supporting new operating systems, fixing bugs, updating to minor versions of libraries... Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present. And every programmer does this, consciously or unconsciously. Say hard-coding some parameters in functions instead of creating user-defined options because it's easier, or writing a specific class instead of an abstract one that can be later extended, or writing a hack instead of refactoring so that new changes fit properly. Of course, it's difficult to predict the future and some technical debt is never repaid. But it's important to make a distinction and to have in mind the technical debt in your project and when it's worth it to remove it.

mytailorisrich 6y ago
Spot on comment. I'd add that there is also a principle of not trying to predict the future and make design over-general and over-flexible 'just in case', but rather to have the simplest design that fits current requirements (though of course it should be clean and follow good practice). The may lead to technical debt in the future but it may not. The idea being not to spend until you have to. Now, a fudge now to save time should only be done under tight schedule with a plan to fix it later... In an ideal world. I think this is the case that really fits the analogy of borrowing/debt. Overall, technical debt is unavoidable in a ever changing, unpredictable environment
- user5994461 6y ago
  I agree that further work is unavoidable in an ever changing environment. Software is built over time with the environment constantly shifting under it, it's a cycle to maintain and extend (constant changes if you will). That's the crux of why technical debt doesn't exist, or is not a receivable term. If it were debt there should be a way not to take it, but there isn't. Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable. One solution to not have debt may be to not write anything, that's not receivable because then there would no product and no company. The other implication is that there may be a perfect state to reach with no debt, but that's not the case, realistically it's not possible to start from code that's perfect and bug free and supports every (future) feature in the universe.

bencollier49 6y ago

It feels to me as though this argument misses the point. -- Technical debt is time that you have borrowed from the future. -- That makes perfectly good sense if you need a simple, working system, quickly. But if you plan on extending it, then the workarounds and shortcuts that you took will need to be replaced, slowing you down in future. Concrete classes where abstractions will be needed in future, hard-coded values, all that stuff. The debt will have to be repaid.

cloudhead 6y ago

Complete nonsense..

pdimitar 6y ago

Pretty low-quality flaming post. Basically "battle of the word definitions". Refactoring is observably the best way to get to know someone's code. Refactoring doesn't have to actually change behaviour; in fact, the word itself means "improving the code without changing its behaviour". Not seeing any value in this post outside of "I disagree with some words, let's use others".

Cthulhu_ 6y ago
This is what I've caught myself doing; instead of reading and trying to understand the code, I scan it and start "fixing" it to make it my own. Writing and changing code is a lot less boring than just reading it. Focusing on details (formatting, function naming, ordering, files) seems to be a lot more "gratifying" than trying to grasp the bigger picture. I guess this is why I'll never become a senior developer / architect. Mind you, atm I don't have anyone else working on the same codebase either so it's all me.
- pdimitar 6y ago
  What's a senior developer? I had zero problems grasping a lot of bigger pictures but since I didn't care much about political and office drama I never was dubbed "senior" while working in offices. At one point I decided for myself that I am senior by the virtue of being able to quickly understand what's happening in a codebase and where the real value-add lies, plus the ability to integrate it into the bigger ecosystem of deployments that the company practices. And having a good general culture. So don't you care about "senior". :) As for the topic -- harmless refactoring is indeed the way to get to know code. This has been said by people like Martin Fowler and Kent Beck so it's not exactly baseless and isn't easily refutable by a flaming post like the OP.

firstbabylonian 6y ago

I agree with this. 'Technical debt' always exists in the heads of the engineers: the rest of the organisation can't see it. It's an invisible problem, imagined by the engineers, and not always in touch with the practical long-term reality. Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. Whereas saying 'technical debt' is like delivering a dramatically vague House MD diagnosis. If you must, call it what it is – Maintenance – and let's move on.

galoisgirl 6y ago
If it exists only in the heads of the engineers, then it's not technical debt. Don't get me wrong, there are problems that mainly exist "in the heads of the engineers". Many of them want to refactor code or migrate to a newer framework or re-write for the latest buzzwords. But that's not technical debt.
ggreer 6y ago
> Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. Yes software is a tool, but unlike physical tools, it does not wear out. Running the same code many times won't cause it to slowly degrade. What does happen with software is that as you adapt it to particular roles, if you're not careful you can make it very hard to re-adapt to new roles. A "new role" doesn't necessarily mean user-facing features. It can be as simple as running on Ubuntu instead of running on RHEL. Or it can involve using a newer (and incompatible) version of some library. It might even be as daunting as porting the software to a new language (eg: from JavaScript to TypeScript). The common analogy used to illustrate this is that of a car. If you have a typical passenger car and you need to compete in a demolition derby, you can modify that car to be a good demolition derby car. But if you're then asked to modify that car to win a track race, you'll have an easier time starting with a new unmodified passenger car than modifying your demolition derby car.
gjulianm 6y ago
> Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept. In that context, maintenance is fixing your screwdriver. Technical debt is having a fixed-head screwdriver instead of another with swappable heads: it might be ok for you if you mainly use that one, but if you're constantly needing to buy new screwdrivers and carry them, it's extra money and work. And the same as technical debt, you might decide to buy first a fixed -head screwdriver because you're not certain about your future needs and it's just cheaper and easier, and then switch to a swappable head when you are certain you need it.

OldHand2018 6y ago

Where I work, "technical debt" is a term used by the project management folks whenever they are looking for justification for forcing developers to do something that everyone knows is a bad idea. No worries, we'll come back to it when we have more time (we never have more time).

Viliam1234 6y ago
> No worries, we'll come back to it when we have more time (we never have more time). There are only two priorities: priority one, and priority "we will actually never do this, because always something else will be priority one". But of course, if it makes the engineers happy, we can put "fixing technical debt" in Jira, and assign it any priority between 2 and 99.

grafelic 6y ago

To me (from an Ops perspective), technical debt is when people who have come before you implemented a setup that is broken at a deep level. A setup which can only be fixed by a complete re-implementation. No amount of maintenance will suffice.

ChrisMarshallNY 6y ago

> This is meant literally. Reading existing code is difficult -more difficult than writing code- thus it is a genuine take from the developer that throwing everything away and starting over from scratch is “easier” than continuing on the existing. [Ergo this is flawed for non-small projects because the new development will never catch up with the existing during the tenure of the developer(s).] I tend to work alone, so the poor schlub that needs to go in and maintain the code is usually Yours Truly. That’s a big reason that I am pretty obsessed with heavily-documented code. I eat my own dog food. It is quite painful to review undocumented codebases; even (especially) really well-written code. I write in Swift, and it’s entirely possible for an experienced Swift programmer to write highly efficient code that is almost completely inscrutable. Not sure I’d necessarily call that “technical debt,” but it’s a real issue. I’ve learned to use naive coding (in reality, highly efficient code often doesn’t buy squat), and a lot of “this is why I did this” commenting, along with long, descriptive entity names[0]; assuming that it’s my goal for my code to be maintained by others, and to not have them constantly pinging me with questions. I will say that the (fairly ambitious) projects I’ve done that have grown into large community efforts, have resulted in very, very few questions about the code. It seems that understanding the code I write, isn’t an issue, for most people. I write code for myself, and that seems to make others happy. [0] https://medium.com/chrismarshallny/leaving-a-legacy-1c2ddb0c8014 https://medium.com/chrismarshallny/leaving-a-legacy-1c2ddb0c...

sixstringtheory 6y ago

Technical debt is not maintenance. Technical debt is the additional maintenance for which you create a need when, presented with multiple options to implement a thing, you take the quickest and dirtiest one. It compounds the more you make decisions like that, just as compounding interest and capitalization create ever higher amounts of monetary debt. Also, I found their self-referenced article on how Windows required more work than the pyramids, using man hours as a metric, simply absurd. This strikes me as a mythical man month type fallacy but can’t quite put my finger on it.

websitescenes 6y ago

Technical debt != maintenance.. Maintenance is just maintenance. Technical debt is having to jump through arbitrary hoops to satisfy a code base or piece of technology instead of being able to directly address the problem at hand. With that said, I do agree that all code has some degree of technical debt but that can be limited by good design.

karmakaze 6y ago

This is all just words and redefinitions, how you choose to slice and label things. Here's the useless reframing: > Software do not have a technical debt problem, software simply requires maintenance. Despite the words used, tech debt does exist. This article doesn't do much to make the task of maintaining software any better. It lumps it all together. Tech debt, created accidentally or purposefully can be reduced with specific forms of maintenance which makes further changes easier and reducing future maintenance efforts.

rdiddly 6y ago

I like the debt metaphor, especially because of 1) interest, which costs more the more debt there is and the longer you carry it, and 2) the fact that sometimes it's smarter to borrow than to be debt free.

IceDane 6y ago

What a vapid, shallow and uninteresting article. Congratulations, you just gave technical debt another name. That doesn't mean it doesn't exist. Maybe you should try reading up on the subject matter next time before writing a blog post so you don't end up rediscovering fire again.

Fire-Dragon-DoL 6y ago

I think the point might be the term? I read somewhere a suggested alternative: product debt. The technical side is the one that loaned the time in terms if shortcut. Paying it back has always a steeper cost. Not only that, it also compounds.