9 ms·

Code Is Not Technical Debt

138 points by gavinhoward 3y ago

Nevermark 3y ago
These endless conversations about what “tech debt” is reveal how poorly matched the term is. Debt is not something useless. Or malformed. It is something you owe. If you sign a contract to produce a feature and get paid up front you have tech debt. Literally. To pay off the owed feature, you produce & ship the feature. If you throw out some feature quickly in a haphazard or buggy way that requires maintenance to operate as advertised (regular manual fixes of data base corruption), you now have operational debt. Literally. To pay off that owed operational commitment, you can fix your bug or keep fixing its impact. Pay off all at once, or for all time. But if you ship a fully functioning feature that works, regardless of its implementation, you don’t owe anything. If the feature had a haphazard design or implementation that is going to slow future development, you have taken a shortcut and reduced the quality of your foundation. Reducing the quality of a foundation due to a shoddy code rework isn’t debt. You don’t owe anything. It’s a destruction of present net value. Present net value is your codes immediate value + its expected contribution to future value. Maintain and increase the “present net value” of your code base by making changes carefully, and investing in its ability to fit future needs.
couchand 3y ago
I'm currently getting nginx 404s on the git of Thesueus links, fyi.
- gavinhoward 3y ago
  I'm sorry! It's fixed now, but for some reason, those images were not uploaded even though they existed.
henriquez 3y ago
Code being technical debt is trivially false. Code is an asset. A house is an asset. A house falls apart if not maintained. So does code. That doesn’t make a house debt, nor code.
- emmelaich 3y ago
  What's the difference between debt and investment(asset)? You won't know until later.
- weego 3y ago
  Code is an asset once proven to be so. I don't get the obsession with trying to condense this down to a single concept. Code is necessary, sometimes we write good code that turns out to be an asset in both the short and long terms, sometimes we write mediocre code which is a short-term asset to our business goals but in the long term turns out to be debt. Sometimes we write bad code that will probably never justify itself as an asset because of the problems it a) causes and b) requires human intervention to support, patch or delete.
- mkoubaa 3y ago
  Software is the asset, not code. A pile of bricks metal plastic and wood is not the asset, the house someone can live in is
  - Jensson 3y ago
    Blueprints for good houses are assets, that is what code for good programs is.
- rickdeckard 3y ago
  And yet, not every assortment of bricks and wood in a backyard is necessarily a house. It must be turned into a house with accepted value first, until then it might even be a liability to the real estate it is piled on. Same applies to code. Also code should first be proven to create value to be valued as an asset. In worst case, it may just be a pile of bricks devaluing the property.
- davidmurdoch 3y ago
  Technical debt isn't limited to maintenance. It's like if a two story house was built on dirt instead of a proper foundation. Or you skipped adding insulation, or you didn't put all the plumbing in.
- 3y ago
washedup 3y ago
Really glad to see this rebuttal. I understand the sentiment behind the post from the other day, and most days when I look at the repos I work on, I feel the same way, but it just isn't true in a general sense. We write code because it is _bottom-line_, valuable as fuck. It really boils down to: time is the most expensive asset around. This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this)
- _heimdall 3y ago
  If I have the time to plan ahead, I much prefer to prepare with a full test suite that I fan rely on before considering a rewrite. Rewrites are difficult to estimate, difficult to pull off, and often demotivating as the work drags on. Having a suite of test coverage that I can reuse for the rewrite both gives me an easy check to make sure functionality isn't lost and a cheap bit of motivation as I see tests slowly turning green.
- _fat_santa 3y ago
  > This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this) According to Joel Spolsky, it's something you should never do[1]. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - washedup 3y ago
    Liking this post, thanks for sharing.
  - rm_-rf_slash 3y ago
    In my experience, the urge to refactor everything stems from one or a few really really badly coded features that waft their smell to the rest of the codebase. The limited from-scratch refactor can be painful in the short term, but after it’s done you realize how much more manageable other features are because you’re no longer mentally burdened by the worst of the codebase.
hiAndrewQuinn 3y ago
I'd rather have technical debt than actual debt, personally.
- VyseofArcadia 3y ago
  A sufficiently jaded software engineer can even think of technical debt as an asset. It's job security.
  - malfist 3y ago
    I code, therefore I am
- bodantogat 3y ago
  In a way, its kinda like financial debt where if the monthly payments on principal/interest are not too bad, I'd rather not refinance.
RedNifre 3y ago
Isn't it more useful to think of code not as an asset but as a liability? As in, instead of code being "produced", you "spend" lines of code when you solve a problem, i.e. "Getting X amount of business value cost us Y lines of code"? As for the phrase "technical debt": While I like the metaphor, in my experience, most people use it as a synonym for "bad code", so I recommend making sure everyone agrees on the same definition before using it.
- chii 3y ago
  > i.e. "Getting X amount of business value cost us Y lines of code"? it's not the lines of code that costs, but time. It may be OK to use lines of code as proxy for time spent - but that sort of assumes that each line took similar amounts of time to write. I am not sure that's really the case, but even if it is, hiring somebody more competent will get more lines in less time! Therefore, why not just measure the time directly?
  - hamandcheese 3y ago
    It costs time to write the code, yes, but the liability of that code existing will cost an additional, unknown amount at some indeterminate time in the future.
    - flkenosad 3y ago
      Or that code existing will bring an additional, unknown at some indeterminate time in the future, cost savings when you go to implement a nearly identical feature and you find out you won't be needing to start from scratch as you already have all this well tested, named and organized code to pull from as you craft a new solution. Your perspective just needs a shift from negative to positive.
      - hamandcheese 3y ago
        I see that happen maybe one or two times a year, at most. Meanwhile I debug broken code literally every day.
bob1029 3y ago
Modeling code as an asset rather than a liability could create a certain culture that drives you off a cliff. When we were looking at code as an asset, we had lots of microservices and sophisticated contracts between them. We advertised this as some kind of inherent product value (it wasn't). Only once we started thinking about code as a liability did we begin making serious progress with our customers relative to our roadmap. We do very little in-house code beyond our core product these days. We got away from custom admin web tools, microservices, fancy SQL, etc. Everything you have to think about is technical debt to me. If you are mentally preoccupied with A, you aren't thinking much about B, C or D. Fewer moving pieces doesn't always mean less code, but it usually does. This also gets into "innovation tokens", etc
- mplanchard 3y ago
  This feels in line with TFA to me. The value of your assets were underwater (their liability exceeded their value) because they didn’t match the problem domain of your business. You’ve now jettisoned those liabilities and are focusing solely on the assets that are valuable, because they match up well to the problems you need to solve.
- topaz0 3y ago
  The fact that it's an asset doesn't mean its value is proportional to the number of lines that are there. Similarly a house is an asset, but not all 1000 sq ft houses are worth the same amount of money.
robflaherty 3y ago
Always liked Reinertsen’s post on reframing tech debt to deferred work. “When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work.” http://reinertsenassociates.com/technical-debt-adding-math-metaphor/ http://reinertsenassociates.com/technical-debt-adding-math-m...
JohnMakin 3y ago
I just want to +1 this because I had mixed feelings about the last post this one addresses and some of the comments made me feel a little insane and I couldn’t figure out why. I can’t think of many times in my career where adding or modifying code made things more difficult, it’s easier the more I put into it, the more I reason through it and make improvements or add features. When I read this post it makes more sense to me, of course I would program this way, because I am very lazy and I don’t like programming for the heck of it, I like building, so any programming that got in the way of me moving faster became an obstacle to be improved or removed if it couldn’t. This is the natural progression of good systems I’ve seen so far in my relatively short experience programming/building (about 11 years if you add school). Anyway thanks for this, I thought I was going crazy. Need to go reread pragmatic programmer again.
pavlov 3y ago
This debate feels like arguing whether real estate is debt or not. It can certainly be that way if you're leveraged to the max, the value of the property has gone down, and you're paying for maintenance. Then you're just losing money on the property. But ideally and commonly real estate is an asset with equity value. It's largely the same with code. It can be a liability, but it should be an asset. And if you don't want that risk on your books, there are increasingly many ways to rent code (SaaS / PaaS / etc.)
- bob1029 3y ago
  I like the analogy with real estate. It has that intrinsic decay element that large systems also suffer from. It also incorporates the "death by 1000 cuts" experience of dealing with a nonstop slew of minor problems week-by-week. In this analogy, I think you could compare vendors like Amazon and Microsoft to Blackstone. Scale is what makes the game work for these players. Very few get wealthy by personally lording over a handful of concerns in a single metro. Our model today is to rent out complexity & infra as much as possible. We don't want to own a single square foot of tech property if we can avoid it. We don't even have physical floor space in our corporate "office". We aren't particularly interested in the construction style or the brand of the lighting fixtures. We just want some kind of generic, air-conditioned box w/ WiFi to exist inside of while we conduct our actual business. The shorter & more flexible the lease terms, the better. If we could, we'd like to pay per minute of occupancy and only while we are on the property. That would be most ideal.
  - tesdinger 3y ago
    Renting is fragile. The landlord decides how long you may stay. Ownership means being in control. I store things I like on my hard drives so I don't lose them when someone else decides it should no longer be available on the Internet .
satellite2 3y ago
Small comment for the author as I'm currently reading, the survival plots end up in 404. Interested to see those though.
- gavinhoward 3y ago
  I apologize! Those plots are there now. My upload did not grab those images even though I had them. And I didn't check because it was past midnight.
wwqrd 3y ago
Maybe it's a scale thing. If you are sologeneer working on your own project, with a singular vision, making tools to make your life simpler is a no-brainer. If you are implementing a feature for stakeholders on a large piece enterprise software, you don't necessarily have knowledge or understanding of helper tools from earlier work, so that's extra overhead to understand anything non-standard. Then when the stakeholders change direction (as they often do), any assumptions in your code may need to be upheld while implementing the next feature. Edit: This is also why it's nice to use widely adopted libraries and frameworks for any helper code. That way a new starter has a chance of understanding what's going on.
wavemode 3y ago
Both authors are somewhat wrong, and both authors are somewhat talking about different things (and thus talking past each other). Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change (unless somehow the underlying system changes), and that he is working on almost entirely by himself. And he's taking conclusions from that and applying them to business software, where the requirements are complex, rarely clear, change weekly in often unpredictable ways, and the development team is large and constantly changing over time (as people leave the company and new people come in). This leads Gavin to conclude it is his own cleverness which keeps his code free of tech debt. Phrases like this give away the confusion: > I also do one more thing that almost no developer does: I actually design my code before I ever start coding. This is all well and good! Until you realize in a few months that the business is going in a new direction, and your big beautiful design is now based on a set of faulty assumptions. You either go back to the drawing board (and lose the business time and money) or those new features are going to be bolted on as ugly hacks. (You might even convince yourself "we'll eventually come back and refactor this, surely." Ha!) As for the original author, his mistake was ascribing causation to a correlation. Since all projects he's ever seen that grow in code size gradually accumulate tech debt, he concluded that it is the increase in code size which caused the tech debt. But in reality - Gavin was correct on this point - programming is about developing a mental model for the solution space. Debt arises when the developers no longer possess an accurate model (which they very often don't, when the model they possess is based on a set of vague requirements, and/or when the model that was correct three months ago is now wrong since the business made some new decisions, and/or when the developers who had an accurate mental model when they were working on the problem three years ago have now left the company and the new team don't possess all of the knowledge and context of that era, et cetera et cetera).
- gavinhoward 3y ago
  > Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had requirements change on me before, and I alluded to this with one tiny phrase: > It can happen in two ways: the problem changes (your liability increases) or your software becomes less useful (your asset depreciates). (Emphasis added.) Code liability is directly tied to both the code and the problem. If the problem changes, including requirements, your liability increases. I still suggest that people design though; the act of doing so sometimes reveals flaws and ambiguity that can be worked through early, even if only partially. And design does help keep your mental model more correct.
elicksaur 3y ago
There are several links that 404 at the time of writing this comment, so maybe this person has more technical debt than they realize?[1] Regardless, my mental model is quickly becoming to ignore anyone talking about “technical debt”. Where’s next week’s blog “All blog posts about technical debt are technical debt”? [1] https://gavinhoward.com/img/bc_stack_plot.png https://gavinhoward.com/img/bc_stack_plot.png
- gavinhoward 3y ago
  I'm sorry! The files exist, but my upload didn't grab them. Fixed now.
  - elicksaur 3y ago
    Thanks for updating! Sorry for being a little cheeky about it!
    - gavinhoward 3y ago
      I deserved it. :)
swader999 3y ago
With AI, I'm less concerned about the sore parts of the app than previously. Waiting for better versions should lower the cost to address it even further. Probably not the most professional way to think about it but it seems like this will be the case.
michaelmior 3y ago
I think one nuance that is missing here is what "product" means. In the most broad sense, tools such as bc and dc are indeed products. However, I think the discussion of technical debt tends to focus more around larger scale products created by commercial development teams. That certainly affects the nature of technical debt.
karmakaze 3y ago
> The post is “All Code Is Technical Debt” written by Paul McMahon. And everything is just slightly wrong, starting from the title. So let’s break it down. Similarly this post's title seems a bit off. If it was "Only some code is tech debt" we would have less disagreement in the comments.
- drewcoo 3y ago
  I was thinking it should have been called "My Code Is Not Technical Debt." It still defeats the "all code" claim, though.
  - kagakuninja 3y ago
    Bob's code is technical debt. Fuck that guy.
Exuma 3y ago
I often think how every headline on HN could be inverted into its 180 degree opposite and it would get as many upvotes. I often also think its crazy how people are painfully unaware of this fact... I swear these have got to be the stupidest headlines, and yet people don't seem to ever have an original thought about it, just for a fraction of a moment..... a moment of awareness that shows them that their factually stated headline is actually 100% not a fact.
- PH95VuimJjqBqy 3y ago
  Maybe stop reading the titles as a statement of fact. I certainly didn't interpret it that way, your statement is obvious enough that it immediately turns the headline into a strongly held opinion.
  - Exuma 3y ago
    When a headline is written as a fact, I see it as a fact. I refuse to read uncreative factually written headlines as any other way, as its basically attempting to spoon feed the reader into some basic idea. This is in a similar way to how CNN or popular news stations talk to you as if you are a 5th grader. I read headlines as they're written, and creative headlines get my attention, and stupid headlines go into the waste bin of all the other stupid headlines stated as facts which are not facts.
    - PH95VuimJjqBqy 3y ago
      that's a you problem.
      - Exuma 3y ago
        There is in fact, no problem at all
        PH95VuimJjqBqy 3y ago
        I too generally post rants on things I don't consider to be a problem...
revskill 3y ago
If code is a good abstraction, it's a valuable asset. Else, it's a liability.
NanoYohaneTSU 3y ago
Hard disagree. Greenfield vs Brownfield experience teaches us differently, you don't need analytics involved. Scope creep doesn't just eat up man hours, it eats up the ability to maintain and bring onboard new people. Learning new features to you doesn't eat your time when you already know the product. Learning new features as newguy is far harder because you don't know the underlying product, but you're expected to know the core product, including all new features. This is tech debt, and all code becomes it, because devs die. Fortunately we end up moving techstacks, which allow the new devs to eliminate that code debt, temporarily. You see this same thing in gaming. Dota 2, LoL, CS, Live Service XYZ are not getting new players because the amount of things you have to learn now vs when the game was new is mountanic.
- flkenosad 3y ago
  How about we start thinking about Org debt. All organizations become debt at the end of the day, you know, because suits die. Fortunately, we end up moving industry norms, which allow the new suits to eliminate that org debt, temporarily. Maybe someday, we can eliminate orgs all together.
taneq 3y ago
Code ain’t code though. Production tested library code is an asset. Known good code from old projects that can be used as reference or easily adapted to new projects is an asset. Project specific glue code is a liability. Streaming mounds of hacked together prototype or testing code are technical debt.
vpfaulkner 3y ago
I like the analogy that code is like weight to an airplane (“Measuring programming progress by lines of code is like measuring aircraft building progress by weight” - Bill Gates). You want enough code to achieve your business objectives but no more since code carries a maintenance cost. I suppose you could say the net value of some code = contribution to business objective - maintenance cost. This also implies that code could have a negative value depending on its business value and maintenance cost
notShabu 3y ago
this debate reminds of kitchen appliances. what makes an appliance a burden or not is how much cognitive load is takes (space taken, where is it stored, how to take apart and clean, how to use, etc..) and how much value it provides. (time saved, quality produced, aesthetics) sometimes it's "debt" when it costs more than it's value produced but this is can be highly dependent on how often it's used. (space taken is a large fixed cost) with code, the space is "infinite" so there's a lot of clutter like "pineapple corer for those with a diameter between 5cm and 10m, corer for those with exactly 12cm, bannana nutella injector, etc.." combine this tension with a changing environment and output requirements (one week steakhouse, next is chinese food, etc...) and everything starts to feel like a pile of crap going "smaller" alleviates this problem b/c a lot of specialized tools are designed for scale. one steak and one chow mein doesn't justify a salamander broiler or a wok
topaz0 3y ago
Having recently gone to a bit of trouble to learn the basics of accounting, I have found it to be quite a useful system. It seems that most commenters here do not understand that system, or what "assets" and "liabilities" are in accounting terms. Assets are stuff you have. Liabilities are expenses that you are expected to owe in the future. Debt is a specific kind of liability associated with repaying loans. There are other liabilities, like maintenance costs, that are not debt. So I agree with the post: there can be liabilities associated with code, but code itself is an asset, according to any sane accounting metaphor at least. Of course (as the post also clarifies), the value of the asset depends on how well it serves a purpose, not how much of it there is or whatever. And its value may in some cases be less than the liabilities (maintenance costs etc) that you owe on it. Nevertheless, it is an asset, a thing you have, with some positive value. (Whether to call the liabilities debt in this metaphor depends on whether it makes sense to say you took out a loan. Maybe in some very abstract sense it works, but it is a bit of a stretch imo. I guess its a nice metaphor because it connects to the idea of why you might want to take out a loan, e.g. because it will help you develop more future income than the cost of the loan. Regardless, even if you want to call it "technical debt", the code would be an asset that you have purchased with the borrowed funds. The debt is what you now owe associated with the loan of those funds.)
- tacone 3y ago
  A notable difference is the liabilities usually have a due date, while technical debt usually have none. Just a though: would assigning a due date to properly refactor the shortcuts we sometimes have to take be a useful exercise to better evaluate the trade off and help it not accumulate too much debt over time?
  - distortionfield 3y ago
    Wouldn’t the due date just be business deadlines in this analogy?
    - tacone 3y ago
      Well no, presumably we usually accumulate technical debt to meet the business deadline, with the hope of getting rid of it later on.

138 points by gavinhoward 3y ago

These endless conversations about what “tech debt” is reveal how poorly matched the term is. Debt is not something useless. Or malformed. It is something you owe. If you sign a contract to produce a feature and get paid up front you have tech debt. Literally. To pay off the owed feature, you produce & ship the feature. If you throw out some feature quickly in a haphazard or buggy way that requires maintenance to operate as advertised (regular manual fixes of data base corruption), you now have operational debt. Literally. To pay off that owed operational commitment, you can fix your bug or keep fixing its impact. Pay off all at once, or for all time. But if you ship a fully functioning feature that works, regardless of its implementation, you don’t owe anything. If the feature had a haphazard design or implementation that is going to slow future development, you have taken a shortcut and reduced the quality of your foundation. Reducing the quality of a foundation due to a shoddy code rework isn’t debt. You don’t owe anything. It’s a destruction of present net value. Present net value is your codes immediate value + its expected contribution to future value. Maintain and increase the “present net value” of your code base by making changes carefully, and investing in its ability to fit future needs.

couchand 3y ago

I'm currently getting nginx 404s on the git of Thesueus links, fyi.

gavinhoward 3y ago
I'm sorry! It's fixed now, but for some reason, those images were not uploaded even though they existed.

henriquez 3y ago

Code being technical debt is trivially false. Code is an asset. A house is an asset. A house falls apart if not maintained. So does code. That doesn’t make a house debt, nor code.

emmelaich 3y ago
What's the difference between debt and investment(asset)? You won't know until later.
weego 3y ago
Code is an asset once proven to be so. I don't get the obsession with trying to condense this down to a single concept. Code is necessary, sometimes we write good code that turns out to be an asset in both the short and long terms, sometimes we write mediocre code which is a short-term asset to our business goals but in the long term turns out to be debt. Sometimes we write bad code that will probably never justify itself as an asset because of the problems it a) causes and b) requires human intervention to support, patch or delete.
mkoubaa 3y ago
Software is the asset, not code. A pile of bricks metal plastic and wood is not the asset, the house someone can live in is
- Jensson 3y ago
  Blueprints for good houses are assets, that is what code for good programs is.
rickdeckard 3y ago
And yet, not every assortment of bricks and wood in a backyard is necessarily a house. It must be turned into a house with accepted value first, until then it might even be a liability to the real estate it is piled on. Same applies to code. Also code should first be proven to create value to be valued as an asset. In worst case, it may just be a pile of bricks devaluing the property.
davidmurdoch 3y ago
Technical debt isn't limited to maintenance. It's like if a two story house was built on dirt instead of a proper foundation. Or you skipped adding insulation, or you didn't put all the plumbing in.
3y ago

washedup 3y ago

Really glad to see this rebuttal. I understand the sentiment behind the post from the other day, and most days when I look at the repos I work on, I feel the same way, but it just isn't true in a general sense. We write code because it is _bottom-line_, valuable as fuck. It really boils down to: time is the most expensive asset around. This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this)

_heimdall 3y ago
If I have the time to plan ahead, I much prefer to prepare with a full test suite that I fan rely on before considering a rewrite. Rewrites are difficult to estimate, difficult to pull off, and often demotivating as the work drags on. Having a suite of test coverage that I can reuse for the rewrite both gives me an easy check to make sure functionality isn't lost and a cheap bit of motivation as I see tests slowly turning green.
_fat_santa 3y ago
> This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this) According to Joel Spolsky, it's something you should never do[1]. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- washedup 3y ago
  Liking this post, thanks for sharing.
- rm_-rf_slash 3y ago
  In my experience, the urge to refactor everything stems from one or a few really really badly coded features that waft their smell to the rest of the codebase. The limited from-scratch refactor can be painful in the short term, but after it’s done you realize how much more manageable other features are because you’re no longer mentally burdened by the worst of the codebase.

hiAndrewQuinn 3y ago

I'd rather have technical debt than actual debt, personally.

VyseofArcadia 3y ago
A sufficiently jaded software engineer can even think of technical debt as an asset. It's job security.
- malfist 3y ago
  I code, therefore I am
bodantogat 3y ago
In a way, its kinda like financial debt where if the monthly payments on principal/interest are not too bad, I'd rather not refinance.

RedNifre 3y ago

Isn't it more useful to think of code not as an asset but as a liability? As in, instead of code being "produced", you "spend" lines of code when you solve a problem, i.e. "Getting X amount of business value cost us Y lines of code"? As for the phrase "technical debt": While I like the metaphor, in my experience, most people use it as a synonym for "bad code", so I recommend making sure everyone agrees on the same definition before using it.

chii 3y ago
> i.e. "Getting X amount of business value cost us Y lines of code"? it's not the lines of code that costs, but time. It may be OK to use lines of code as proxy for time spent - but that sort of assumes that each line took similar amounts of time to write. I am not sure that's really the case, but even if it is, hiring somebody more competent will get more lines in less time! Therefore, why not just measure the time directly?
- hamandcheese 3y ago
  It costs time to write the code, yes, but the liability of that code existing will cost an additional, unknown amount at some indeterminate time in the future.
  - flkenosad 3y ago
    Or that code existing will bring an additional, unknown at some indeterminate time in the future, cost savings when you go to implement a nearly identical feature and you find out you won't be needing to start from scratch as you already have all this well tested, named and organized code to pull from as you craft a new solution. Your perspective just needs a shift from negative to positive.
    - hamandcheese 3y ago
      I see that happen maybe one or two times a year, at most. Meanwhile I debug broken code literally every day.

bob1029 3y ago

Modeling code as an asset rather than a liability could create a certain culture that drives you off a cliff. When we were looking at code as an asset, we had lots of microservices and sophisticated contracts between them. We advertised this as some kind of inherent product value (it wasn't). Only once we started thinking about code as a liability did we begin making serious progress with our customers relative to our roadmap. We do very little in-house code beyond our core product these days. We got away from custom admin web tools, microservices, fancy SQL, etc. Everything you have to think about is technical debt to me. If you are mentally preoccupied with A, you aren't thinking much about B, C or D. Fewer moving pieces doesn't always mean less code, but it usually does. This also gets into "innovation tokens", etc

mplanchard 3y ago
This feels in line with TFA to me. The value of your assets were underwater (their liability exceeded their value) because they didn’t match the problem domain of your business. You’ve now jettisoned those liabilities and are focusing solely on the assets that are valuable, because they match up well to the problems you need to solve.
topaz0 3y ago
The fact that it's an asset doesn't mean its value is proportional to the number of lines that are there. Similarly a house is an asset, but not all 1000 sq ft houses are worth the same amount of money.

robflaherty 3y ago

Always liked Reinertsen’s post on reframing tech debt to deferred work. “When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work.” http://reinertsenassociates.com/technical-debt-adding-math-metaphor/ http://reinertsenassociates.com/technical-debt-adding-math-m...

JohnMakin 3y ago

I just want to +1 this because I had mixed feelings about the last post this one addresses and some of the comments made me feel a little insane and I couldn’t figure out why. I can’t think of many times in my career where adding or modifying code made things more difficult, it’s easier the more I put into it, the more I reason through it and make improvements or add features. When I read this post it makes more sense to me, of course I would program this way, because I am very lazy and I don’t like programming for the heck of it, I like building, so any programming that got in the way of me moving faster became an obstacle to be improved or removed if it couldn’t. This is the natural progression of good systems I’ve seen so far in my relatively short experience programming/building (about 11 years if you add school). Anyway thanks for this, I thought I was going crazy. Need to go reread pragmatic programmer again.

pavlov 3y ago

This debate feels like arguing whether real estate is debt or not. It can certainly be that way if you're leveraged to the max, the value of the property has gone down, and you're paying for maintenance. Then you're just losing money on the property. But ideally and commonly real estate is an asset with equity value. It's largely the same with code. It can be a liability, but it should be an asset. And if you don't want that risk on your books, there are increasingly many ways to rent code (SaaS / PaaS / etc.)

bob1029 3y ago
I like the analogy with real estate. It has that intrinsic decay element that large systems also suffer from. It also incorporates the "death by 1000 cuts" experience of dealing with a nonstop slew of minor problems week-by-week. In this analogy, I think you could compare vendors like Amazon and Microsoft to Blackstone. Scale is what makes the game work for these players. Very few get wealthy by personally lording over a handful of concerns in a single metro. Our model today is to rent out complexity & infra as much as possible. We don't want to own a single square foot of tech property if we can avoid it. We don't even have physical floor space in our corporate "office". We aren't particularly interested in the construction style or the brand of the lighting fixtures. We just want some kind of generic, air-conditioned box w/ WiFi to exist inside of while we conduct our actual business. The shorter & more flexible the lease terms, the better. If we could, we'd like to pay per minute of occupancy and only while we are on the property. That would be most ideal.
- tesdinger 3y ago
  Renting is fragile. The landlord decides how long you may stay. Ownership means being in control. I store things I like on my hard drives so I don't lose them when someone else decides it should no longer be available on the Internet .

satellite2 3y ago

Small comment for the author as I'm currently reading, the survival plots end up in 404. Interested to see those though.

gavinhoward 3y ago
I apologize! Those plots are there now. My upload did not grab those images even though I had them. And I didn't check because it was past midnight.

wwqrd 3y ago

Maybe it's a scale thing. If you are sologeneer working on your own project, with a singular vision, making tools to make your life simpler is a no-brainer. If you are implementing a feature for stakeholders on a large piece enterprise software, you don't necessarily have knowledge or understanding of helper tools from earlier work, so that's extra overhead to understand anything non-standard. Then when the stakeholders change direction (as they often do), any assumptions in your code may need to be upheld while implementing the next feature. Edit: This is also why it's nice to use widely adopted libraries and frameworks for any helper code. That way a new starter has a chance of understanding what's going on.

wavemode 3y ago

Both authors are somewhat wrong, and both authors are somewhat talking about different things (and thus talking past each other). Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change (unless somehow the underlying system changes), and that he is working on almost entirely by himself. And he's taking conclusions from that and applying them to business software, where the requirements are complex, rarely clear, change weekly in often unpredictable ways, and the development team is large and constantly changing over time (as people leave the company and new people come in). This leads Gavin to conclude it is his own cleverness which keeps his code free of tech debt. Phrases like this give away the confusion: > I also do one more thing that almost no developer does: I actually design my code before I ever start coding. This is all well and good! Until you realize in a few months that the business is going in a new direction, and your big beautiful design is now based on a set of faulty assumptions. You either go back to the drawing board (and lose the business time and money) or those new features are going to be bolted on as ugly hacks. (You might even convince yourself "we'll eventually come back and refactor this, surely." Ha!) As for the original author, his mistake was ascribing causation to a correlation. Since all projects he's ever seen that grow in code size gradually accumulate tech debt, he concluded that it is the increase in code size which caused the tech debt. But in reality - Gavin was correct on this point - programming is about developing a mental model for the solution space. Debt arises when the developers no longer possess an accurate model (which they very often don't, when the model they possess is based on a set of vague requirements, and/or when the model that was correct three months ago is now wrong since the business made some new decisions, and/or when the developers who had an accurate mental model when they were working on the problem three years ago have now left the company and the new team don't possess all of the knowledge and context of that era, et cetera et cetera).

gavinhoward 3y ago
> Gavin here is talking about the development of system software, where the requirements are perfectly clear, rarely change This is not true. I've had requirements change on me before, and I alluded to this with one tiny phrase: > It can happen in two ways: the problem changes (your liability increases) or your software becomes less useful (your asset depreciates). (Emphasis added.) Code liability is directly tied to both the code and the problem. If the problem changes, including requirements, your liability increases. I still suggest that people design though; the act of doing so sometimes reveals flaws and ambiguity that can be worked through early, even if only partially. And design does help keep your mental model more correct.

elicksaur 3y ago

There are several links that 404 at the time of writing this comment, so maybe this person has more technical debt than they realize?[1] Regardless, my mental model is quickly becoming to ignore anyone talking about “technical debt”. Where’s next week’s blog “All blog posts about technical debt are technical debt”? [1] https://gavinhoward.com/img/bc_stack_plot.png https://gavinhoward.com/img/bc_stack_plot.png

gavinhoward 3y ago
I'm sorry! The files exist, but my upload didn't grab them. Fixed now.
- elicksaur 3y ago
  Thanks for updating! Sorry for being a little cheeky about it!
  - gavinhoward 3y ago
    I deserved it. :)

swader999 3y ago

With AI, I'm less concerned about the sore parts of the app than previously. Waiting for better versions should lower the cost to address it even further. Probably not the most professional way to think about it but it seems like this will be the case.

michaelmior 3y ago

I think one nuance that is missing here is what "product" means. In the most broad sense, tools such as bc and dc are indeed products. However, I think the discussion of technical debt tends to focus more around larger scale products created by commercial development teams. That certainly affects the nature of technical debt.

karmakaze 3y ago

> The post is “All Code Is Technical Debt” written by Paul McMahon. And everything is just slightly wrong, starting from the title. So let’s break it down. Similarly this post's title seems a bit off. If it was "Only some code is tech debt" we would have less disagreement in the comments.

drewcoo 3y ago
I was thinking it should have been called "My Code Is Not Technical Debt." It still defeats the "all code" claim, though.
- kagakuninja 3y ago
  Bob's code is technical debt. Fuck that guy.

Exuma 3y ago

I often think how every headline on HN could be inverted into its 180 degree opposite and it would get as many upvotes. I often also think its crazy how people are painfully unaware of this fact... I swear these have got to be the stupidest headlines, and yet people don't seem to ever have an original thought about it, just for a fraction of a moment..... a moment of awareness that shows them that their factually stated headline is actually 100% not a fact.

PH95VuimJjqBqy 3y ago
Maybe stop reading the titles as a statement of fact. I certainly didn't interpret it that way, your statement is obvious enough that it immediately turns the headline into a strongly held opinion.
- Exuma 3y ago
  When a headline is written as a fact, I see it as a fact. I refuse to read uncreative factually written headlines as any other way, as its basically attempting to spoon feed the reader into some basic idea. This is in a similar way to how CNN or popular news stations talk to you as if you are a 5th grader. I read headlines as they're written, and creative headlines get my attention, and stupid headlines go into the waste bin of all the other stupid headlines stated as facts which are not facts.
  - PH95VuimJjqBqy 3y ago
    that's a you problem.
    - Exuma 3y ago
      There is in fact, no problem at all
      - PH95VuimJjqBqy 3y ago
        I too generally post rants on things I don't consider to be a problem...

revskill 3y ago

If code is a good abstraction, it's a valuable asset. Else, it's a liability.

NanoYohaneTSU 3y ago

Hard disagree. Greenfield vs Brownfield experience teaches us differently, you don't need analytics involved. Scope creep doesn't just eat up man hours, it eats up the ability to maintain and bring onboard new people. Learning new features to you doesn't eat your time when you already know the product. Learning new features as newguy is far harder because you don't know the underlying product, but you're expected to know the core product, including all new features. This is tech debt, and all code becomes it, because devs die. Fortunately we end up moving techstacks, which allow the new devs to eliminate that code debt, temporarily. You see this same thing in gaming. Dota 2, LoL, CS, Live Service XYZ are not getting new players because the amount of things you have to learn now vs when the game was new is mountanic.

flkenosad 3y ago
How about we start thinking about Org debt. All organizations become debt at the end of the day, you know, because suits die. Fortunately, we end up moving industry norms, which allow the new suits to eliminate that org debt, temporarily. Maybe someday, we can eliminate orgs all together.

taneq 3y ago

Code ain’t code though. Production tested library code is an asset. Known good code from old projects that can be used as reference or easily adapted to new projects is an asset. Project specific glue code is a liability. Streaming mounds of hacked together prototype or testing code are technical debt.

vpfaulkner 3y ago

I like the analogy that code is like weight to an airplane (“Measuring programming progress by lines of code is like measuring aircraft building progress by weight” - Bill Gates). You want enough code to achieve your business objectives but no more since code carries a maintenance cost. I suppose you could say the net value of some code = contribution to business objective - maintenance cost. This also implies that code could have a negative value depending on its business value and maintenance cost

notShabu 3y ago

this debate reminds of kitchen appliances. what makes an appliance a burden or not is how much cognitive load is takes (space taken, where is it stored, how to take apart and clean, how to use, etc..) and how much value it provides. (time saved, quality produced, aesthetics) sometimes it's "debt" when it costs more than it's value produced but this is can be highly dependent on how often it's used. (space taken is a large fixed cost) with code, the space is "infinite" so there's a lot of clutter like "pineapple corer for those with a diameter between 5cm and 10m, corer for those with exactly 12cm, bannana nutella injector, etc.." combine this tension with a changing environment and output requirements (one week steakhouse, next is chinese food, etc...) and everything starts to feel like a pile of crap going "smaller" alleviates this problem b/c a lot of specialized tools are designed for scale. one steak and one chow mein doesn't justify a salamander broiler or a wok

topaz0 3y ago

Having recently gone to a bit of trouble to learn the basics of accounting, I have found it to be quite a useful system. It seems that most commenters here do not understand that system, or what "assets" and "liabilities" are in accounting terms. Assets are stuff you have. Liabilities are expenses that you are expected to owe in the future. Debt is a specific kind of liability associated with repaying loans. There are other liabilities, like maintenance costs, that are not debt. So I agree with the post: there can be liabilities associated with code, but code itself is an asset, according to any sane accounting metaphor at least. Of course (as the post also clarifies), the value of the asset depends on how well it serves a purpose, not how much of it there is or whatever. And its value may in some cases be less than the liabilities (maintenance costs etc) that you owe on it. Nevertheless, it is an asset, a thing you have, with some positive value. (Whether to call the liabilities debt in this metaphor depends on whether it makes sense to say you took out a loan. Maybe in some very abstract sense it works, but it is a bit of a stretch imo. I guess its a nice metaphor because it connects to the idea of why you might want to take out a loan, e.g. because it will help you develop more future income than the cost of the loan. Regardless, even if you want to call it "technical debt", the code would be an asset that you have purchased with the borrowed funds. The debt is what you now owe associated with the loan of those funds.)

tacone 3y ago
A notable difference is the liabilities usually have a due date, while technical debt usually have none. Just a though: would assigning a due date to properly refactor the shortcuts we sometimes have to take be a useful exercise to better evaluate the trade off and help it not accumulate too much debt over time?
- distortionfield 3y ago
  Wouldn’t the due date just be business deadlines in this analogy?
  - tacone 3y ago
    Well no, presumably we usually accumulate technical debt to meet the business deadline, with the hope of getting rid of it later on.