17 ms·

We sound like idiots when we talk about technical debt

130 points by seekayel 5y ago

dqpb 5y ago
Maybe supply chain is a better analogy than debt. Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.
k__ 5y ago
Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's always good to have an excuse to work slower.
- willis936 5y ago
  Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not interesting.
  - drcongo 5y ago
    I _love_ maintenance and fixing technical debt, much more than working on features.
    - fendy3002 5y ago
      And it's easier though if you have different skillset than feature development. Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.
  - matthewmacleod 5y ago
    I don't think I've ever worked in an environment where the tech team would have resisted the opportunity to take some time to refactor or update some systems that needed attention. In fact, they'd most likely be overjoyed and would much rather do this than implement features. YMMV from team to team, though.
  - thinkharderdev 5y ago
    I agree. I think people on HN generally underestimate the extent to which developers themselves push to work on new features instead of maintenance. It's often a different kind of feature though. I can't count how many times in my career devs (including me!) instantly jumped to "we need to rewrite X using new framework Y" in response to technical debt in X.
    - k__ 5y ago
      I only saw that behavior in younger devs. The average dev just does their job. Same as with the average person in every industry. Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.
- drcongo 5y ago
  Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.
  - perrygeo 5y ago
    Exactly this. The author's dev-blaming perspective is that Tech Debt costs are not accounted for systematically nor communicated clearly to the business folks. Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.
- andrew_ 5y ago
  > Why? Because it's always good to have an excuse to work slower. Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.
adrianN 5y ago
Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.
- thanatos519 5y ago
  It's extremely hard to quantify the impact of any changes to a system so "inventing numbers to get what you want" is required whenever stakeholders are obsessed with predictability and quantification.
- edelans 5y ago
  This. I came here to express exactly the same feeling, but I think you wrote it better than me !
- gonzo41 5y ago
  I find I have to head check myself from having negative thoughts about approaches that I wouldn't have taken. Like seeing old java, or bootstrap :P. It still works, fixing it may make things neater, but does that really pay down debt?
  - samhw 5y ago
    Yeah, this feeling is ubiquitous among programmers (or 'developers' perhaps), and I suspect it's a large reason why businesspeople are suspicious of "we need to invest time paying down tech debt". There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".
- marginalia_nu 5y ago
  I get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that). Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the future of the project. If you want to compel someone in charge to make changes, you need to make them feel things are bad as well. This is to be used responsibly, though. If it turns out you've convinced someone into acting in a way that is against their interest or a big waste of time, there will probably be blowback later.
avidphantasm 5y ago
Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits of dealing with technical debt before it is too late.
- EarthLaunch 5y ago
  That reminds me of a hidden cost of technical debt: Who wants to work for you. Technical debt is not just unpleasant, it's a signal of desperation or shortsightedness.
EarthLaunch 5y ago
Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money. Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It's relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn't learned about financial instruments. King: We need to raise an army. Duke: Okay, but we're out of money. We'd have to borrow more. King: Are we able to borrow money for it? Duke: Yes, but our debts are racking up, and there could be future consequences. King: Sounds like we can borrow money, do it.
- magicalhippo 5y ago
  A better term might be "technical mass". Having lots of it makes it harder to quickly implement changes and features. It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it. Though if business folks didn't take physics classes it might not resonate well with them.
  - muzani 5y ago
    Technical calories then?
  - verve_rat 5y ago
    I like that. More mass slows everything down and makes changing direction harder.
- muzani 5y ago
  That's exactly how startups think, though. The king raises an army to conquer rich lands and pay off debt. The founder makes hacky products, to get users, then raises money to hire engineers.
  - EarthLaunch 5y ago
andi999 5y ago
I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.
- moffkalast 5y ago
  Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."
  - andi999 5y ago
    Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off" of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"
    - moffkalast 5y ago
      Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.
      - andi999 5y ago
        Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.
        marcosdumay 5y ago
        > compared to the imagined/perceived value I guess the word you are looking for is "necessary".
trwhite 5y ago
The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.
- leghifla 5y ago
  I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.
  - trwhite 5y ago
    That's true. So I suppose I would amend to say "if the line is exponential". At the company I work for presently we try to adopt "painful now, pleasurable later".
- carlivar 5y ago
  Agreed, and I also think measuring "rework" helps. For a car company, rework could be recalls or warranty claims. For a software company it can be outages or incidents, especially those with major customer impact.
- rco8786 5y ago
  Never in the history of software has that line done anything but gone up. Software naturally gets more complex as it grows to handle new features, new edge cases, more users, more backwards compatibility, etc. This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.
  - marcosdumay 5y ago
    Most software has short periods when it goes down. And then go up again. I think the correct framing is that it should go up only with the logarithm of the code's age or size. If it's going any faster, you have a problem.
- 5y ago
thinkharderdev 5y ago
This article seemed pretty incoherent: > Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value. And then literally two sentences later: > They care about time to market.
- Gupie 5y ago
  The first is in regards medium/long term maintenance. Whereas time to market usually refers to the first version of a product.
Tretio 5y ago
Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault. And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt. Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation." "Ah sry I can't work longer today I already have a reservation" "On the weekend? Mh I booked a hotel already" "How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update." "I can prioritize your new request but I will talk to x to tell him that his task will be delayed." "Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"
- EugeneOZ 5y ago
  Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.
  - Tretio 5y ago
    I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
    - EugeneOZ 5y ago
      And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
      - 5y ago
wokwokwok 5y ago
Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever. Almost no one has a job of 'go do this really slowly and carefully'. They will always pick fast, and it's your problem later. So... don't do that. Instead, say: this is how long it will take to do. Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'? Say: This is how long it will take, we estimate. If you want it faster, we can cut some features. Then, do enough of a good job so you can continue to deliver value in the future. That's literally your job. Doing a rubbish job as quickly as you can is not your job. Not ever. You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it". That's YOU choosing to do a rubbish job. ...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.
- rusticpenn 5y ago
  Unfortunately it does not work in reality. There will be another guy who is ready to do "fast and dirty", and he will be give the responsibility and probably will lead the team in future.
  - magicalhippo 5y ago
    Guess it depends on your management. I've often told my boss the feature would be easy, but I would also like to take the time to clean up the code in the affected area since it's making it harder than it should be to implement changes. And I've gotten some time extra to do just that. Other times I say doing it fast and cheap is possible, but I see an opportunity here to do something more clever and involved which will very likely open up further possibilities down the line. For example, I might predict other clients will need a similar feature, so by making my code a bit more general it should be easier to implement if they come asking for their variant. Sometimes I get a green light on that, sometimes I do not. I guess it helps that the owners are playing the long game, so my boss can afford to see beyond the next quarter.
amznbyebyebye 5y ago
One trick we use is to just bake it in as part of a new medium to large size feature. Or if product is swamped with stakeholder management related stuff, we leave a gap sprint for all these tech debt related things. Another thing we do is have a dedicated platform team whose main charter is to work on general improvements inclusive of tech debt reduction.
mberning 5y ago
You have to tie it to something they want or need. They “need” to be on the latest version -> upgrading versions takes a long time and is prone to error -> the process would be infinitely easier with a robust test suite -> we never prioritized automated testing which is a tech debt which we are now paying interest on in the form of being on extremely old versions of a product.
hobs 5y ago
People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull request because he had control. Just because YOU have never been in a situation where YOU didn't have control over the creation of technical debt doesn't mean its just some magical thing you can fix and change by saying the right words, don't be naive.
- samhw 5y ago
  It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.
  - hobs 5y ago
    For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
    - samhw 5y ago
      Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.
  - foxfluff 5y ago
    > It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand. Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly." Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.
choeger 5y ago
Maintenance also has a second aspect: Bitrot. Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem. The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: "We won't be able to ship/develop after day X because big OSS project Y deprecated our version" (think CentOS repository deletion). It is our job to keep an eye on this and report it in the terms management understands: "We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities."
- samhw 5y ago
  This is a really excellent constructive way of framing it. Thanks for posting this!
tcgv 5y ago
Techincal debt is a typicall long term problem without a short term solution. Product managers are biased towards delivering short term value incrementally, and don't like anything that slows down the value delivery pipeline.
syntaxfree 5y ago
This isn’t that complicated. Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former. But financial debt is authorized by corporate finance, which is empowered to do so by the C-suite and implicitly by shareholders. Whereas technical debt is created at ones own risk by the Individual Contributor, who didn’t ask the shareholders if they liked the trade off.
catlifeonmars 5y ago
Speculation ahead: One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).
- the_sleaze9 5y ago
  I have anecdotal support with a sample size of 1: This happened to me. I genuinely wanted to care, and wanted to improve the situation, but found I was slowing down (1), introducing bugs with every merge (2) and finally I just left (3). Business began with a certain idea, then over time pivoted into into better and better, mostly related niches for users. What that meant in terms of the code base is we started with one thing then tried to back-port it in several new directions and ended up with a gigantic ball of spaghetti. Great job, great coworkers, great technical management. Code base just became so rotted and so overextended, it became untenable.
- andrew_ 5y ago
  Absolutely agree. I moved on from a very high level engineering position last August for exactly these reasons. A mountain of technical debt the size and breadth of the Rockies that was not being addressed was dragging everyone down. I'd had enough. Leadership at my current position understands what technical debt means, they understand the technical reasons given for calling it such, and the impact not only on business but also development time and DX.
- CyberRabbi 5y ago
  If dealing with technical debt has a toll on one’s mental health then maybe they should transition to a different profession. Dealing with technical debt is part of your job description. Most people don’t have the luxury of ignoring the hard parts of their job.
  - catlifeonmars 5y ago
    It’s not about luxury, it’s about increasing output efficiency through (human) resource management. I asked if there was any available research that measures the effect of tech debt on mental health and therefore output efficiency. TBH, I’m not really sure which part of my original comment you are addressing. Edit: clarification.
shakezula 5y ago
Agree with the headline. I've always preferred to use code as mass as the analogy, because inertia, friction, etc... are more applicable to the situation than money and debt, imo.
chillage 5y ago
I use a couple pretty simple measures to get the technical debt idea across, with the numbers variable: "if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%" Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.
andrew_ 5y ago
This reads to me as an incredibly reductive take on a real-world problem, offloading blame/responsibility to engineers to properly frame something which very few engineers fully comprehend or can intelligently convey. I understand the author is trying to teach how to frame it, but it still requires experience and skill that I've seen very little of during my career in all but the most experienced or talented engineers. Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they'll understand. "We" the engineers don't sound like idiots - "we're" being literal, which is all "our" job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.
hermannj314 5y ago
If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are renegotiated. Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has 'technical debt' too. It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn't there because 'its not the customers's problem'
- Pamar 5y ago
  I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word. - If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future... - If the lawyer who was originally part of the team that helped draft the old law... etc.
  - xionon 5y ago
    I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.
    - Pamar 5y ago
      My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.
      - deleted 5y ago
cestith 5y ago
Perhaps technical debt is the wrong term to use with nontechnical people, who tend to startle that they aren't even meant to understand so soon as the "tech" part comes out of someone's mouth. If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we've taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.
- wobbly_bush 5y ago
  > perhaps we should call technical debt what it really is to the business: temporal debt If they startle at the mention of "tech", how are they not going to be startled with "temporal"?
  - cestith 5y ago
    Then just say "time". Honestly, if your director, CIO, and CEO don't have a decent vocabulary then perhaps explaining this issue isn't your firm's biggest problem.
commandlinefan 5y ago
What's really frustrating is that technical debt leads to real problems. It's just that these problems have been so pervasive for so long that everybody just accepts them like a bad smell that you don't really notice. Technical debt is the underlying root of: - you said you fixed this problem but I'm still seeing it - you fixed this problem but you created a new one - we can't deploy a fix for this problem right away because we have to certify the whole monolithic mess first - testing this fix takes an hour to coordinate These are problems that business owners should care about, but they've just come to accept that this is the reality of software development.
tristor 5y ago
I think the metaphor for technical debt is leaky, but I don't think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to "rushing things", but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I've seen technical debt addressed successfully in a fairly long (~18 years) career: 1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions. 2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.
trunnell 5y ago
A "culture of approvals" is one root cause of this situation. Something needs to be done, but instead of doing it an engineer asks someone else for approval and doesn't receive it. Healthy teams don't work that way. In a healthy team, engineers are responsible for the health of the system. In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the relative priority of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.
jimbokun 5y ago
> The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be. Time to market is also absolutely impacted by technical debt, for the same reasons. Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward." Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.
- nickysielicki 5y ago
  > Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward." I’d argue that technical debt that can be resolved in a week is not real technical debt. And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without lying through your teeth. “It will probably take us a month to two months to fix this problem and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.
  - jimbokun 5y ago
    > and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale. Which indicates there really isn't much quantifiable value in the refactoring, and it's probably a poor use of developer time.
Tarucho 5y ago
Part of the problem is the twisted naming we are using for development related things. Tech debt, ceremonies, sprints, masters, squads, etc. Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.
corry 5y ago
One of the things I struggle with in the perennial conversations about technical debt at startups is how to account for the fact that the future in not known with certainty: i.e. circumstances can change that render very good and 'worth-it' (but expensive) technical decisions obsolete in future. My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to 'do it right' vs 'do it fast', since they believe that EVEN IF it's 'right' today, it probably won't be 'right' tomorrow and we'll have to rewrite/re-do/refactor to accommodate the new paradigm/circumstances. Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. "prepaying" the cost of fixing the future problem.
Jtsummers 5y ago
Techie: We are drowning in technical debt! Business person: Oh really! What is it costing us? Correct response: Techie: Every new release is taking longer and longer to complete. When we don't give ourselves the time, we have more bugs that are driving away customers. Time is money, business people understand that. Address that aspect of the issue.
dasil003 5y ago
Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater. The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain. Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc. What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.
cweagans 5y ago
IMO: software engineers have a professional responsibility to mitigate technical debt (among other things). Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit. Software engineers should not _ask permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there's no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them. There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don't just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.
- selfhoster11 5y ago
  Part of the problem is that the job of an accountant, lawyer, electrician (and presumably a mechanic) has that responsibility and duty of care imposed by law. If a client is pushing you to cut corners that are illegal to cut, you point them at the law book and tell them to piss off with their meddling. And because it's illegal, everyone in your jurisdiction will have to do the same thing, thereby assuring that the outcome of this particular Prisoner's Dilemma is rigged in advance except for the most foolish/risk tolerant who are willing to break the law. The software profession has no such thing, for the most part. So clients will keep probing and meddling, just like toddlers who want to know how much they can get away with before their parents punish the misbehaviour. And if some people die, or suffer from algorithms gone wrong, or are just generally pissed off left and right because of bad software - who cares. Profits are king, right?
  - cweagans 5y ago
    Without legally imposed duty of care, the only thing that can be done to draw a line in the sand is to commit (collectively) to maintaining a reasonable level of professional practice. Simply do not entertain probing and meddling. "It's going to take a little longer because the software is complex and it takes some time to untangle it" is all you need to say. Whether you refactor/test/document it in the process of understanding it is irrelevant.
CyberRabbi 5y ago
Great post. One of the major problems is that software engineering is saturated with green devs who recently transitioned from hobbyist coding and don’t fully understand the responsibilities of being a professional. Hobbyist projects are rarely held to external constraints. Usually when the hobbyist dislikes the code he has thus far written, he will rewrite it instead of iterating on it because he has that luxury since nothing depends on his project. Unfortunately in the real world, we have to consider other factors aside from what the author prefers to work on. This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.
adityaathalye 5y ago
Hah :) I've also had a recent blog-post length thought about this entitled: "Technical Debt is really Software Debt. And it’s a AAA-rated CDO." https://www.evalapply.org/posts/software-debt https://www.evalapply.org/posts/software-debt Context: > I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel. > One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge. (More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :) Edit: add some context from the blog post.
renewiltord 5y ago
Tech debt is a thought terminating cliche. Progress is possible more easily if we talk in a Markov fashion: under present circumstances, to get X, we need to do Y. The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision. Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”
gilbetron 5y ago
I get the using "debt" is an attempt to make it understandable to financial-oriented people, but I think it is a double-edged sword. You have to pay off financial debt, you don't have to pay off technical debt. I think using "technical friction" is a better approach. You are increasing the cost of future projects. "Cutting corners on that will increase the cost of all future efforts by 10%". That is more impactful and conveys the situation better. Likewise, "well, we cut corners here last year to get the demo made, so now this project takes 25% more time." Even if we SWAG the percentages (which, guess what, financial-oriented people do all the time!), it lets Product Owners and Managers make better decisions.
- Nomentatus 5y ago
  I'm with you, I agree we gotta drop the "D" word. There's no bank to go to to extend the loan. The "interest" isn't necessarily low or negotiable or even predictable. Way too misleading. But I'm wondering if we shouldn't be saying "preventative maintenance" and sometimes just "repair" (for example if there's already an error rate, as in the article's last example.) Of course, then ya gotta answer the question "to prevent what?" To which the answer is "SNAFUs" or "gremlins" (pardon the WWII terms) such as ones that will make all coding work more expensive later on or will horrify customers by their effects. Or just kill the business outright. I've seen that happen, after having been firmly refused permission to do preventive maintainance on my code. (I'm a worse coder but a better salesman now, so that probably wouldn't happen, now.) Does this stretch the word repair? No, I think if you're replacing disc brake pads on an old car after X amount of miles, that's repair even if you can still stop the car. In other words, maybe this has been solved in other ordinary economic contexts, and we should just be brave enough to use them thar words.
phendrenad2 5y ago
We sound like idiots because we treat businesspeople like idiots. We parrot a definition of tech debt we got from a blog post. The whole analogy to debt is a hand-wavy joke of a definition anyway. It's not debt, it's a liability that's depreciating the assets of the company intellectual property. The only reason it looks like debt is because it compounds, which is ironically something people don't really focus on when discussing it with management. People don't want to look incompetent so they say "Feature X took 3x as long as it should have, because we had some tech debt". It's implied that the tech debt is resolved. But in most cases the reality is, the time was spent just working around the tech debt, and the tech debt is not resolved. And now you've entrenched even more workarounds and hacks that will make things worse. Compound interest baby.
0xbadcafebee 5y ago
If you have a car, and drive it 100 miles every day, and keep driving it for years, it will seem like everything is fine. Until one day the engine seizes up and it unexpectedly costs you $5,000 to fix, because you never changed the oil or did any other maintenance. There was never any apparent, obvious reason that maintenance was required. But no regular maintenance does lead to unexpected high costs. It is critical that technical people have data to back up their claims that maintenance is needed. We need to identify exactly what each piece of tech debt is, how much work is needed to remediate it, and what the business cost of not remediating it is. Otherwise the business has literally zero idea what it will cost them not to do maintenance. This is an expected part of professional software engineering in a business. If you are not gathering this data and presenting it to leadership, do not expect them to take you seriously. It is up to you to prove your case.
namelessoracle 5y ago
My experience dealing with product managers is you have to phrase it one of 2 ways. If you know your taking technical debt, explain to them that its like a credit card, but instead of money its time, and we can go ahead and swipe it, but you will eventually have to pay it with interest, and the cost you are paying is every future story is gonna be a little bit slower until things that should be able to get done in a week take a month. ( I have seen this happen personally with a project and the whole thing had to get completely rewritten) If its unforeseen technical debt, dont call it that. Call it foundational work. Tell them the foundations were not set in a way to support X or Y feature so we need to change/update the foundations to get them the feature they want. This seems to work best. Don't even tell them there is a hack or duct tape solution, bring up the foundational piece first. If business needs has a requirement that it gets out faster, then transition to the credit card analogy and explain they are now swiping the credit card and whenever they complain about velocity use this an example. The biggest problem is that product managers typically move on or get promoted by the time the technical debt they incurred causes bankruptcy. And fixing that usually tends to involve a rewrite which will have new flavors of technical debt (especially when its in new language), with a new product manager selling their "V2 solution" as so much better. (and successful delivery of that seems to involve them getting promoted or moving to another place soon after)
scotty79 5y ago
If Big Corp co is paying per man-hour doing a thing in a week that could be done in a day is actually huge win from the point of view of a business person. Everything should be done as slow as possible as long as client isn't annoyed enough to change providers. Business people both at your company and at Big Corp co customer benefit from keeping things as they are for as long as possible. They keep getting paid for as long as the project lasts. But when the project finishes, a lot can go wrong. It might turn out that it was completely unnecessary or that it doesn't solve the problem it was supposed to solve or that any given business person no longer has any utility for the respective companies. Basically a lot of trouble. So technical debt might be something business people actually silently treasure.

130 points by seekayel 5y ago

dqpb 5y ago

Maybe supply chain is a better analogy than debt. Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.

k__ 5y ago

Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's always good to have an excuse to work slower.

willis936 5y ago
Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not interesting.
- drcongo 5y ago
  I _love_ maintenance and fixing technical debt, much more than working on features.
  - fendy3002 5y ago
    And it's easier though if you have different skillset than feature development. Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.
- matthewmacleod 5y ago
  I don't think I've ever worked in an environment where the tech team would have resisted the opportunity to take some time to refactor or update some systems that needed attention. In fact, they'd most likely be overjoyed and would much rather do this than implement features. YMMV from team to team, though.
- thinkharderdev 5y ago
  I agree. I think people on HN generally underestimate the extent to which developers themselves push to work on new features instead of maintenance. It's often a different kind of feature though. I can't count how many times in my career devs (including me!) instantly jumped to "we need to rewrite X using new framework Y" in response to technical debt in X.
  - k__ 5y ago
    I only saw that behavior in younger devs. The average dev just does their job. Same as with the average person in every industry. Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.
drcongo 5y ago
Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.
- perrygeo 5y ago
  Exactly this. The author's dev-blaming perspective is that Tech Debt costs are not accounted for systematically nor communicated clearly to the business folks. Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.
andrew_ 5y ago
> Why? Because it's always good to have an excuse to work slower. Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.

adrianN 5y ago

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

thanatos519 5y ago
It's extremely hard to quantify the impact of any changes to a system so "inventing numbers to get what you want" is required whenever stakeholders are obsessed with predictability and quantification.
edelans 5y ago
This. I came here to express exactly the same feeling, but I think you wrote it better than me !
gonzo41 5y ago
I find I have to head check myself from having negative thoughts about approaches that I wouldn't have taken. Like seeing old java, or bootstrap :P. It still works, fixing it may make things neater, but does that really pay down debt?
- samhw 5y ago
  Yeah, this feeling is ubiquitous among programmers (or 'developers' perhaps), and I suspect it's a large reason why businesspeople are suspicious of "we need to invest time paying down tech debt". There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".
marginalia_nu 5y ago
I get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that). Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the future of the project. If you want to compel someone in charge to make changes, you need to make them feel things are bad as well. This is to be used responsibly, though. If it turns out you've convinced someone into acting in a way that is against their interest or a big waste of time, there will probably be blowback later.

avidphantasm 5y ago

Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits of dealing with technical debt before it is too late.

EarthLaunch 5y ago
That reminds me of a hidden cost of technical debt: Who wants to work for you. Technical debt is not just unpleasant, it's a signal of desperation or shortsightedness.

EarthLaunch 5y ago

Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money. Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It's relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn't learned about financial instruments. King: We need to raise an army. Duke: Okay, but we're out of money. We'd have to borrow more. King: Are we able to borrow money for it? Duke: Yes, but our debts are racking up, and there could be future consequences. King: Sounds like we can borrow money, do it.

magicalhippo 5y ago
A better term might be "technical mass". Having lots of it makes it harder to quickly implement changes and features. It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it. Though if business folks didn't take physics classes it might not resonate well with them.
- muzani 5y ago
  Technical calories then?
- verve_rat 5y ago
  I like that. More mass slows everything down and makes changing direction harder.
muzani 5y ago
That's exactly how startups think, though. The king raises an army to conquer rich lands and pay off debt. The founder makes hacky products, to get users, then raises money to hire engineers.
- EarthLaunch 5y ago

andi999 5y ago

I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.

moffkalast 5y ago
Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."
- andi999 5y ago
  Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off" of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"
  - moffkalast 5y ago
    Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.
    - andi999 5y ago
      Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.
      - marcosdumay 5y ago
        > compared to the imagined/perceived value I guess the word you are looking for is "necessary".

trwhite 5y ago

The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.

leghifla 5y ago
I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.
- trwhite 5y ago
  That's true. So I suppose I would amend to say "if the line is exponential". At the company I work for presently we try to adopt "painful now, pleasurable later".
carlivar 5y ago
Agreed, and I also think measuring "rework" helps. For a car company, rework could be recalls or warranty claims. For a software company it can be outages or incidents, especially those with major customer impact.
rco8786 5y ago
Never in the history of software has that line done anything but gone up. Software naturally gets more complex as it grows to handle new features, new edge cases, more users, more backwards compatibility, etc. This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.
- marcosdumay 5y ago
  Most software has short periods when it goes down. And then go up again. I think the correct framing is that it should go up only with the logarithm of the code's age or size. If it's going any faster, you have a problem.
5y ago

thinkharderdev 5y ago

This article seemed pretty incoherent: > Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value. And then literally two sentences later: > They care about time to market.

Gupie 5y ago
The first is in regards medium/long term maintenance. Whereas time to market usually refers to the first version of a product.

Tretio 5y ago

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault. And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt. Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation." "Ah sry I can't work longer today I already have a reservation" "On the weekend? Mh I booked a hotel already" "How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update." "I can prioritize your new request but I will talk to x to tell him that his task will be delayed." "Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"

EugeneOZ 5y ago
Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.
- Tretio 5y ago
  I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
  - EugeneOZ 5y ago
    And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
    - 5y ago

wokwokwok 5y ago

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever. Almost no one has a job of 'go do this really slowly and carefully'. They will always pick fast, and it's your problem later. So... don't do that. Instead, say: this is how long it will take to do. Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'? Say: This is how long it will take, we estimate. If you want it faster, we can cut some features. Then, do enough of a good job so you can continue to deliver value in the future. That's literally your job. Doing a rubbish job as quickly as you can is not your job. Not ever. You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it". That's YOU choosing to do a rubbish job. ...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.

rusticpenn 5y ago
Unfortunately it does not work in reality. There will be another guy who is ready to do "fast and dirty", and he will be give the responsibility and probably will lead the team in future.
- magicalhippo 5y ago
  Guess it depends on your management. I've often told my boss the feature would be easy, but I would also like to take the time to clean up the code in the affected area since it's making it harder than it should be to implement changes. And I've gotten some time extra to do just that. Other times I say doing it fast and cheap is possible, but I see an opportunity here to do something more clever and involved which will very likely open up further possibilities down the line. For example, I might predict other clients will need a similar feature, so by making my code a bit more general it should be easier to implement if they come asking for their variant. Sometimes I get a green light on that, sometimes I do not. I guess it helps that the owners are playing the long game, so my boss can afford to see beyond the next quarter.

amznbyebyebye 5y ago

One trick we use is to just bake it in as part of a new medium to large size feature. Or if product is swamped with stakeholder management related stuff, we leave a gap sprint for all these tech debt related things. Another thing we do is have a dedicated platform team whose main charter is to work on general improvements inclusive of tech debt reduction.

mberning 5y ago

You have to tie it to something they want or need. They “need” to be on the latest version -> upgrading versions takes a long time and is prone to error -> the process would be infinitely easier with a robust test suite -> we never prioritized automated testing which is a tech debt which we are now paying interest on in the form of being on extremely old versions of a product.

hobs 5y ago

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull request because he had control. Just because YOU have never been in a situation where YOU didn't have control over the creation of technical debt doesn't mean its just some magical thing you can fix and change by saying the right words, don't be naive.

samhw 5y ago
It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.
- hobs 5y ago
  For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
  - samhw 5y ago
    Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.
- foxfluff 5y ago
  > It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand. Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly." Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.

choeger 5y ago

Maintenance also has a second aspect: Bitrot. Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem. The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: "We won't be able to ship/develop after day X because big OSS project Y deprecated our version" (think CentOS repository deletion). It is our job to keep an eye on this and report it in the terms management understands: "We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities."

samhw 5y ago
This is a really excellent constructive way of framing it. Thanks for posting this!

tcgv 5y ago

Techincal debt is a typicall long term problem without a short term solution. Product managers are biased towards delivering short term value incrementally, and don't like anything that slows down the value delivery pipeline.

syntaxfree 5y ago

This isn’t that complicated. Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former. But financial debt is authorized by corporate finance, which is empowered to do so by the C-suite and implicitly by shareholders. Whereas technical debt is created at ones own risk by the Individual Contributor, who didn’t ask the shareholders if they liked the trade off.

catlifeonmars 5y ago

Speculation ahead: One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).

the_sleaze9 5y ago
I have anecdotal support with a sample size of 1: This happened to me. I genuinely wanted to care, and wanted to improve the situation, but found I was slowing down (1), introducing bugs with every merge (2) and finally I just left (3). Business began with a certain idea, then over time pivoted into into better and better, mostly related niches for users. What that meant in terms of the code base is we started with one thing then tried to back-port it in several new directions and ended up with a gigantic ball of spaghetti. Great job, great coworkers, great technical management. Code base just became so rotted and so overextended, it became untenable.
andrew_ 5y ago
Absolutely agree. I moved on from a very high level engineering position last August for exactly these reasons. A mountain of technical debt the size and breadth of the Rockies that was not being addressed was dragging everyone down. I'd had enough. Leadership at my current position understands what technical debt means, they understand the technical reasons given for calling it such, and the impact not only on business but also development time and DX.
CyberRabbi 5y ago
If dealing with technical debt has a toll on one’s mental health then maybe they should transition to a different profession. Dealing with technical debt is part of your job description. Most people don’t have the luxury of ignoring the hard parts of their job.
- catlifeonmars 5y ago
  It’s not about luxury, it’s about increasing output efficiency through (human) resource management. I asked if there was any available research that measures the effect of tech debt on mental health and therefore output efficiency. TBH, I’m not really sure which part of my original comment you are addressing. Edit: clarification.

shakezula 5y ago

Agree with the headline. I've always preferred to use code as mass as the analogy, because inertia, friction, etc... are more applicable to the situation than money and debt, imo.

chillage 5y ago

I use a couple pretty simple measures to get the technical debt idea across, with the numbers variable: "if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%" Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.

andrew_ 5y ago

This reads to me as an incredibly reductive take on a real-world problem, offloading blame/responsibility to engineers to properly frame something which very few engineers fully comprehend or can intelligently convey. I understand the author is trying to teach how to frame it, but it still requires experience and skill that I've seen very little of during my career in all but the most experienced or talented engineers. Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they'll understand. "We" the engineers don't sound like idiots - "we're" being literal, which is all "our" job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.

hermannj314 5y ago

If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are renegotiated. Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has 'technical debt' too. It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn't there because 'its not the customers's problem'

Pamar 5y ago
I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word. - If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future... - If the lawyer who was originally part of the team that helped draft the old law... etc.
- xionon 5y ago
  I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.
  - Pamar 5y ago
    My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.
    - deleted 5y ago

cestith 5y ago

Perhaps technical debt is the wrong term to use with nontechnical people, who tend to startle that they aren't even meant to understand so soon as the "tech" part comes out of someone's mouth. If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we've taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.

wobbly_bush 5y ago
> perhaps we should call technical debt what it really is to the business: temporal debt If they startle at the mention of "tech", how are they not going to be startled with "temporal"?
- cestith 5y ago
  Then just say "time". Honestly, if your director, CIO, and CEO don't have a decent vocabulary then perhaps explaining this issue isn't your firm's biggest problem.

commandlinefan 5y ago

What's really frustrating is that technical debt leads to real problems. It's just that these problems have been so pervasive for so long that everybody just accepts them like a bad smell that you don't really notice. Technical debt is the underlying root of: - you said you fixed this problem but I'm still seeing it - you fixed this problem but you created a new one - we can't deploy a fix for this problem right away because we have to certify the whole monolithic mess first - testing this fix takes an hour to coordinate These are problems that business owners should care about, but they've just come to accept that this is the reality of software development.

tristor 5y ago

I think the metaphor for technical debt is leaky, but I don't think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to "rushing things", but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I've seen technical debt addressed successfully in a fairly long (~18 years) career: 1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions. 2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.

trunnell 5y ago

A "culture of approvals" is one root cause of this situation. Something needs to be done, but instead of doing it an engineer asks someone else for approval and doesn't receive it. Healthy teams don't work that way. In a healthy team, engineers are responsible for the health of the system. In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the relative priority of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.

jimbokun 5y ago

> The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be. Time to market is also absolutely impacted by technical debt, for the same reasons. Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward." Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.

nickysielicki 5y ago
> Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward." I’d argue that technical debt that can be resolved in a week is not real technical debt. And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without lying through your teeth. “It will probably take us a month to two months to fix this problem and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.
- jimbokun 5y ago
  > and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale. Which indicates there really isn't much quantifiable value in the refactoring, and it's probably a poor use of developer time.

Tarucho 5y ago

Part of the problem is the twisted naming we are using for development related things. Tech debt, ceremonies, sprints, masters, squads, etc. Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.

corry 5y ago

One of the things I struggle with in the perennial conversations about technical debt at startups is how to account for the fact that the future in not known with certainty: i.e. circumstances can change that render very good and 'worth-it' (but expensive) technical decisions obsolete in future. My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to 'do it right' vs 'do it fast', since they believe that EVEN IF it's 'right' today, it probably won't be 'right' tomorrow and we'll have to rewrite/re-do/refactor to accommodate the new paradigm/circumstances. Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. "prepaying" the cost of fixing the future problem.

Jtsummers 5y ago

Techie: We are drowning in technical debt! Business person: Oh really! What is it costing us? Correct response: Techie: Every new release is taking longer and longer to complete. When we don't give ourselves the time, we have more bugs that are driving away customers. Time is money, business people understand that. Address that aspect of the issue.

dasil003 5y ago

Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater. The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain. Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc. What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.

cweagans 5y ago

IMO: software engineers have a professional responsibility to mitigate technical debt (among other things). Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit. Software engineers should not _ask permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there's no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them. There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don't just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.

selfhoster11 5y ago
Part of the problem is that the job of an accountant, lawyer, electrician (and presumably a mechanic) has that responsibility and duty of care imposed by law. If a client is pushing you to cut corners that are illegal to cut, you point them at the law book and tell them to piss off with their meddling. And because it's illegal, everyone in your jurisdiction will have to do the same thing, thereby assuring that the outcome of this particular Prisoner's Dilemma is rigged in advance except for the most foolish/risk tolerant who are willing to break the law. The software profession has no such thing, for the most part. So clients will keep probing and meddling, just like toddlers who want to know how much they can get away with before their parents punish the misbehaviour. And if some people die, or suffer from algorithms gone wrong, or are just generally pissed off left and right because of bad software - who cares. Profits are king, right?
- cweagans 5y ago
  Without legally imposed duty of care, the only thing that can be done to draw a line in the sand is to commit (collectively) to maintaining a reasonable level of professional practice. Simply do not entertain probing and meddling. "It's going to take a little longer because the software is complex and it takes some time to untangle it" is all you need to say. Whether you refactor/test/document it in the process of understanding it is irrelevant.

CyberRabbi 5y ago

Great post. One of the major problems is that software engineering is saturated with green devs who recently transitioned from hobbyist coding and don’t fully understand the responsibilities of being a professional. Hobbyist projects are rarely held to external constraints. Usually when the hobbyist dislikes the code he has thus far written, he will rewrite it instead of iterating on it because he has that luxury since nothing depends on his project. Unfortunately in the real world, we have to consider other factors aside from what the author prefers to work on. This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.

adityaathalye 5y ago

Hah :) I've also had a recent blog-post length thought about this entitled: "Technical Debt is really Software Debt. And it’s a AAA-rated CDO." https://www.evalapply.org/posts/software-debt https://www.evalapply.org/posts/software-debt Context: > I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel. > One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge. (More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :) Edit: add some context from the blog post.

renewiltord 5y ago

Tech debt is a thought terminating cliche. Progress is possible more easily if we talk in a Markov fashion: under present circumstances, to get X, we need to do Y. The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision. Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”

gilbetron 5y ago

I get the using "debt" is an attempt to make it understandable to financial-oriented people, but I think it is a double-edged sword. You have to pay off financial debt, you don't have to pay off technical debt. I think using "technical friction" is a better approach. You are increasing the cost of future projects. "Cutting corners on that will increase the cost of all future efforts by 10%". That is more impactful and conveys the situation better. Likewise, "well, we cut corners here last year to get the demo made, so now this project takes 25% more time." Even if we SWAG the percentages (which, guess what, financial-oriented people do all the time!), it lets Product Owners and Managers make better decisions.

Nomentatus 5y ago
I'm with you, I agree we gotta drop the "D" word. There's no bank to go to to extend the loan. The "interest" isn't necessarily low or negotiable or even predictable. Way too misleading. But I'm wondering if we shouldn't be saying "preventative maintenance" and sometimes just "repair" (for example if there's already an error rate, as in the article's last example.) Of course, then ya gotta answer the question "to prevent what?" To which the answer is "SNAFUs" or "gremlins" (pardon the WWII terms) such as ones that will make all coding work more expensive later on or will horrify customers by their effects. Or just kill the business outright. I've seen that happen, after having been firmly refused permission to do preventive maintainance on my code. (I'm a worse coder but a better salesman now, so that probably wouldn't happen, now.) Does this stretch the word repair? No, I think if you're replacing disc brake pads on an old car after X amount of miles, that's repair even if you can still stop the car. In other words, maybe this has been solved in other ordinary economic contexts, and we should just be brave enough to use them thar words.

phendrenad2 5y ago

We sound like idiots because we treat businesspeople like idiots. We parrot a definition of tech debt we got from a blog post. The whole analogy to debt is a hand-wavy joke of a definition anyway. It's not debt, it's a liability that's depreciating the assets of the company intellectual property. The only reason it looks like debt is because it compounds, which is ironically something people don't really focus on when discussing it with management. People don't want to look incompetent so they say "Feature X took 3x as long as it should have, because we had some tech debt". It's implied that the tech debt is resolved. But in most cases the reality is, the time was spent just working around the tech debt, and the tech debt is not resolved. And now you've entrenched even more workarounds and hacks that will make things worse. Compound interest baby.

0xbadcafebee 5y ago

If you have a car, and drive it 100 miles every day, and keep driving it for years, it will seem like everything is fine. Until one day the engine seizes up and it unexpectedly costs you $5,000 to fix, because you never changed the oil or did any other maintenance. There was never any apparent, obvious reason that maintenance was required. But no regular maintenance does lead to unexpected high costs. It is critical that technical people have data to back up their claims that maintenance is needed. We need to identify exactly what each piece of tech debt is, how much work is needed to remediate it, and what the business cost of not remediating it is. Otherwise the business has literally zero idea what it will cost them not to do maintenance. This is an expected part of professional software engineering in a business. If you are not gathering this data and presenting it to leadership, do not expect them to take you seriously. It is up to you to prove your case.

namelessoracle 5y ago

My experience dealing with product managers is you have to phrase it one of 2 ways. If you know your taking technical debt, explain to them that its like a credit card, but instead of money its time, and we can go ahead and swipe it, but you will eventually have to pay it with interest, and the cost you are paying is every future story is gonna be a little bit slower until things that should be able to get done in a week take a month. ( I have seen this happen personally with a project and the whole thing had to get completely rewritten) If its unforeseen technical debt, dont call it that. Call it foundational work. Tell them the foundations were not set in a way to support X or Y feature so we need to change/update the foundations to get them the feature they want. This seems to work best. Don't even tell them there is a hack or duct tape solution, bring up the foundational piece first. If business needs has a requirement that it gets out faster, then transition to the credit card analogy and explain they are now swiping the credit card and whenever they complain about velocity use this an example. The biggest problem is that product managers typically move on or get promoted by the time the technical debt they incurred causes bankruptcy. And fixing that usually tends to involve a rewrite which will have new flavors of technical debt (especially when its in new language), with a new product manager selling their "V2 solution" as so much better. (and successful delivery of that seems to involve them getting promoted or moving to another place soon after)

scotty79 5y ago

If Big Corp co is paying per man-hour doing a thing in a week that could be done in a day is actually huge win from the point of view of a business person. Everything should be done as slow as possible as long as client isn't annoyed enough to change providers. Business people both at your company and at Big Corp co customer benefit from keeping things as they are for as long as possible. They keep getting paid for as long as the project lasts. But when the project finishes, a lot can go wrong. It might turn out that it was completely unnecessary or that it doesn't solve the problem it was supposed to solve or that any given business person no longer has any utility for the respective companies. Basically a lot of trouble. So technical debt might be something business people actually silently treasure.