13 ms·

Using Technical Debt in Your Favor

163 points by treyhuffine 9y ago

arethuza 9y ago
I've often thought that what software projects need is some equivalent of a balance sheet and P&L report - "assets" and "liabilities" together with "income" and "expenditure" equivalents. Looking at technical debt in isolation and always regarding it as a bad thing always seemed simplistic to me.
- humanrebar 9y ago
  Agreed. I've seen teams use no metrics. And I've seen teams use one or two metrics. I haven't seen management deal with complexity like a professional analyst for a pro sports club would: with a range of different metrics to inform human judgements.
  - sharemywin 9y ago
    That's because it's just a way for tech people to sell work, that shows no immediate benefit to the business, to accountants, who sign the checks, that don't like debt.
  - noxToken 9y ago
    How do you measure complexity with an objective number? I have a few ideas for what could go into it for a given task or process (number of branching paths, number of methods called, LOC, time to develop, etc.) but how do you assign weights to these?
    - humanrebar 9y ago
      > ...how do you assign weights to [metrics] To start with, you don't. Baseball managers and scouts look at a lot of metrics: runs, hits, walks, OBP, VAR, number of pitches in a career, convicted felonies, etc. But at the end of the day, there are people making judgement calls. They're just, ideally, exceptionally well-informed people. So what I'd like to see, at least initially, is a healthier universe of metrics we can automatically grab from code bases. Deciders can set up dashboards or reports for those as needed. There would still be actual conversations and decisions involving actual humans, but they'd be looking at this data as they're having qualitative discussions about their options.
    - dllthomas 9y ago
      https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity (relevant, not a complete answer by any stretch)
  - s73v3r_ 9y ago
    What would those metrics be?
humanrebar 9y ago
Sure, and credit cards can be a good thing, too. The problem is that most non-technical and formerly-technical project managers just charge everything to their credit cards and don't even know they own debt and are making interest payments on it. When that's the level of awareness the average development team is dealing with, there's limited practical purpose in exploring the nuances of healthy debt management. It's more useful to talk about technical debt like nutritionists talk about empty calories and transfats.
- allyjweir 9y ago
  I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those. The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.
- rebeccaskinner 9y ago
  I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of the average HN reader. Because you're right, PMs don't have the insight to understand the nuances of technical debt and the benefits and costs associated with varied approaches, and really it's not their job to. As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. Regardless of how much PMs might want things or fiddle with the schedule, as professionals it's our job- not theirs- to say when things can't be done, shouldn't be attempted, or might cost more than they're worth.
  - snarfy 9y ago
    You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
nautilus12 9y ago
I'm starting to see a trend in hacker news stories of the type: Why bad for you thing is actually good for you. or Why thing everybody likes is not so great after all. Is everyone on hacker news just a compulsive contrarian?
- humanrebar 9y ago
  We read "man bites dog" stories, not "dog bites man" stories. Exceptions are inherently more newsworthy.
  - yen223 9y ago
    The danger is that readers may be led to believe that the exceptions are the norm.
- sharemywin 9y ago
  I would have to disagree
- reificator 9y ago
  > Is everyone on hacker news just a compulsive contrarian? No we're not.
  - nathan_long 9y ago
    I am!
    - your-nanny 9y ago
      Yes, possibly maybe. Oh never mind.
      - cirgue 9y ago
        I disagree with you, though I am not sure where that puts me.
fimdomeio 9y ago
Best part is the narration and how Mr. computer says a lot of "undefined" in the middle of the text. :love
allyjweir 9y ago
From my recent experience in a new team, this article strikes a chord. Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily. We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.
- wes-k 9y ago
  "premature optimization is the root of all evil" - Knuth
- bpicolo 9y ago
  I'd argue that "simple, clearly tested" code is the antithesis of technical debt anyway.
- spdionis 9y ago
  > making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily I would say that's just bad engineering due to lack of insight or experience. DRY is the most simple and most dangerous principle (or "best-practice") of them all, because when it goes wrong it's the one that hurts the most.
  - allyjweir 9y ago
    Yes I agree. Bad engineering led them to not accepting the reality that technical debt is unavoidable. In a misguided attempt to avoid it, they overengineered ironically leading to more debt than might otherwise have accrued.
- wvenable 9y ago
  > For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily. That's just another form of technical debt. Over-engineering is also a well known cause of debt accumulation.
zeroxfe 9y ago
Managing technical debt is one of them most important parts of engineering. When you're resource constrained, which is almost a given in the real world, you need to think carefully about what kinds of debts are worth accruing, and what kinds are absolutely not. I think this is both an art and a science, and the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture. There are so many factors involved that it's not surprising so many projects accrue horrible debt.
- raverbashing 9y ago
  Also, some debts are not even debts, but normal limitations of the code If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt
  - Cthulhu_ 9y ago
    It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.
    - beersigns 9y ago
      Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.
      - aldanor 9y ago
        Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).
candu 9y ago
Information presentation nit: did anyone else find those "mental model" diagrams really hard to parse? (Especially the first one.)
- bloudermilk 9y ago
  Agreed, skipped over these. The rest of the content was golden.
bandrami 9y ago
That's a decent argument for bottom-up programming. Though I'd also say what's really at issue here is short term vs. long term technical debt. Writing software bottom-up front-loads some short term technical debt but leaves you much better able to avoid long-term technical debt because you have a much more flexible product.
blauditore 9y ago
There's a fine line between iterative development ("first do it, then do it right, then do it fast") and actual technical dept caused by bad practices (e.g. copy-and-edit instead of re-use). The former method is well-aware of shortcomings and heading towards eliminating them eventually, so I'm not sure if it should even be called technical debt. Actual technical debt (like real life debt) has the problem of "interest" attached to it, so it grows exponentially. So if you're not constantly working to reduce it, it may grow out of hand quickly.
bloudermilk 9y ago
Fantastic article. As an engineering manager working for a lot of young startups, I’ve found technical debt to be inevitable. The author seems to have come to the same conclusion I have: embrace technical debt by leveraging it conciously and tracking it carefully.
paulie_a 9y ago
Technical debt is a debt that someone else will have to pay off. My greatest accomplishment at my current job has been deleting 45K-60K lines of code. Not every bit of code will be perfect for many reasons, but please be thoughtful at least, and not just hammer out code. Someone else is going to have to clean up your mess.
- endorphone 9y ago
  On the flip side, be thoughtful that your job exists because that code was hammered out. I've created loads of technical debt over my career, in the process literally creating whole product lines that later became the career home for teams of people.
- ozim 9y ago
  Funny thing is that technical debt is not like money debt. There is a lot of possibilities that this debt will just be deleted, obsoleted, project discontinued. So it is more like survivorship bias, you only get to fix debt that is still alive. Debt that went away and no one is ever paying it is nowhere to be seen.
  - PeterisP 9y ago
    Bankruptcy is one way to erase debt, and the most horrible debts go out that way. So it's like survivorship bias, where the most important technical debt (the one that kills its project) is often not noticed.
j45 9y ago
Technical debt can benefit from being managed in it's own category - it's inevitable as bugs and features. Unmanaged technical debt is sometimes the 'bad' technical debt we think and read about in hindsight. When I'm a little more aware of technical debt being created - I track and manage it just like a feature or a bug in the project management system. Separate type, label or category of ticket. It surprising several tools don't have this out of the box for some reason. There's a few benefits to technical Debt being categorized separately: Tracking technical debt helps provide a sense of the technical debt tickets that are being opened, and floating around both in numbers, size and unknowns. Keeping technical debt items tracked along side features, and bugs in it's own category is an invaluable form of cross-training to new team members who are learning the why the current code base came to be how it is, and not just what they may see or think is best. We see how good we might be as a team and individually at identifying technical debt, and if we are improving at identifying it, and help develop a ratio for future accuracy. Regular technical debt review helps create a sense of what technical debt is occurring, and what can be fixed under the hood on another project, if desired, or possible. Keeping an eye on technical debt is important too, if something initially small is at risk of painting the project into a corner, or becoming exponentially difficult to re-factor. Would love to hear strategies and tactics you might use in your TD practice.
- convolvatron 9y ago
  even if its not timely to implement - design the replacement right away, and update it if necessary. this helps scope the work, understand what other components are being effected, and allows related systems to be written with an eye towards the fixed version instead of the damaged one.
  - j45 9y ago
    That's a really good idea. We make the technical debt ticket anyways describing the problem, taking a few more minutes to describe "how it should be" so a design process can begin... it will be much easier to pick it up later on... maybe even tie it to an ongoing Technical Debt Roadmap that can be tied into the main product roadmap.
nwhatt 9y ago
A lesson I learned early in my career was to avoid spinning out too much on why a particular piece of code someone else wrote was so “bad”. The metaphor in this article fits perfectly- the developer who wrote this borrowed from the future, and without being there at the time, I can’t really judge their calculations.
- taneq 9y ago
  Also, ugly code that solves a problem for your customers is worth more (ie. is more 'good') than pretty code which doesn't. Customers don't care what the back-end looks like, they just want their problem solved, and pretty code never increased revenue.
skrebbel 9y ago
I'd say that technical debt is often the best kind of debt you can take on as a startup. Difficult to maintain code is not going to be the thing that puts you out of business. Usually that's making the wrong product or not being able to reach your market. Compare that to the other kinds of debt (convertible, for instance). They cost a lot of time to obtain and, potentially, a lot of money in the long run if you do well. Many of the most successful startups had (have?) shitty code. Of course there's great counterexamples (i.e. WhatsApp having a 5 person backend team when they were acquired), but as a programmer and founder I find that my urge to make shitty code and ship fast is waay smaller than my urge to make fantastic beautiful code. Of course shipping fast does not imply writing crap code in general. At all. But sometimes it does, and when it does, I've learned that hard way that maybe it's better to choose the crap code.
- marcosdumay 9y ago
  How often being unable to change your code is the cause of bad product-market fit? How does needing 40 people instead of 5 to run your infrastructure compares with the carry cost of monetary debt? If you were only arguing that the people around here probably needs to be more open to technical debt because we here are mostly perfectionists I would probably agree. But I don't think I can agree with most of what is your post.
  - skrebbel 9y ago
    By the time we can afford to pay 5(!), let alone 40 people to run our infrastructure, I don't think you can call us a startup anymore. This is my point exactly. Until you've found product market fit, the size of the infrastructure team "once you're big" should be the least of your concerns. Personally I don't understand how any tech company with a 5+ person infrastructure team can still be called a startup (unless the infrastructure is the product ofc, eg if you're a PaaS or something)
mikekchar 9y ago
I'd like to quibble a bit with the definition of technical debt being used. A decision not to refactor code when you don't know if you will be improving it is not technical debt in my book. There are many times when I look at a piece of code and say, "This is a smell here, but until we know better what we are building I can't remove the smell". It actually would be technical debt if I covered up the smell with something pretty that wasn't related to what I actually needed. Later on I'll have to remove that pretty code (or work around it). Hopefully making me feel better about apparent lack of smells is worth it ;-) The idea of technical debt is that you are trading some kind of completeness/correctness in the code for something else that is valuable. Usually that valuable thing is time, but it can be something else. For example, perhaps you know that your requirements are wrong. However, the client is unhappy with answering questions. You could pester them some more, or you could implement the obviously wrong requirements and wait for them to find the problem themselves. In this way you defer the frustration of your client to a later time when they might be more approachable. It should go without saying that you should almost never do the above: I'm only using it as an example of tech debt that isn't to do with saving time. There are lots of times where technical debt is beneficial. The key is to understand the cost/benefit. This is where we usually go wrong. The cost/benefit analysis is usually done by someone who only understands the benefit. It's just making the analysis of borrowing money and making the assumption that you don't have to pay it back. Hmm... how much money should I borrow in that case? Obviously, as much as I can get!
snowwrestler 9y ago
I think this is just another way of saying "avoid gold-plating." Building a new service to stand up to millions of users and nation-state attackers is probably overkill until you know whether anyone actually wants it. That said, there are definitely early technical decisions that will be very painful to change later on, like how you authenticate users and protect PII.
Drdrdrq 9y ago
There are different kinds od technical debt. One should aim to keep abstractions simple, and to be able to refactor as quickly as possible. But that also means that the code should be manageable. Unreadable code is never a good thing, and will slow down development considerably.
sdmadf2834 9y ago
"Technical Debt is most of the time used as a negative connotation, but it doesn't need to be like that all the time. It's like taking a loan. It will allow you to deliver software faster in adverse circumstances without having to invest enough time to find the best design for a problem." Lol yeah, taking out a loan for all your future hires to pay back later.
davidhyde 9y ago
"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it?" In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design."
coldacid 9y ago
A far better title for this article, given the content, would have been "How to Manage the Inevitable Technical Debt of your Projects".
davidhyde 9y ago
"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it? In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design." I found the article excellent and I like the financial debt metaphor a lot. However, the quote above is somewhat confusing. I usually get rid of technical debt (post task) so that a developer can read and understand the code better. They need to do this in order to make some future unknown change. Since a "better design" would at least involve understanding the current design then a strongly disagree with leaving technical debt in code you do not think will be touched again.
- toss1 9y ago
  While it's excellent to make the code readable for the next guy, I read this as talking about the architecture level, where reading the code will be largely unnecessary because it is all junked for Rev.2 I did this for one SAAS company and it worked out great. Although I had been very much a design-everything, pre-optimize excessively type of coder/designer, for this project at a company I co-founded I went completely the opposite direction. With only a slight nod to the architecture I expected we'd need later, I just coded up the first version in the easiest high-level tools we had, separating only one module. This allowed us to get a much better handle on the actual requirements, especially since the marketing guys of course went out and sold some of the prototype. Fortunately the sales were small enough that we didn't get swamped, but it gave me real data, and strongly reinforced my plan to build a highly modular set of interacting services such that each could run on separate hardware, which could also be scaled in hours. This very scaleable architecture later allowed us to take business from competitors who were (AFAICT) were stuck in a monolithic architecture. But after the first version had served it's purpose, no one has ever read any of the code again in the 15 yrs since. We just started on the main version and never looked back. So as a person who formerly would have recommended the opposite, I can strongly recommend making a really brief Plan A prototype / first version that you plan to throw away. Just make sure that you do actually throw it away, and soon (code that sort-of works does have a way of sticking around too long).
  - davidhyde 9y ago
arca_vorago 9y ago
I know most here are focused on the dev side of things, but coming from the sysadmin side where I've had to deal with the technical debt of devs + the entire rest of the business IT technical debt, it is anything but good. I've seen the insides of hundred of companies, and the number one cause of technical debt is lack of proper manpower to work ratios. Usually due to short term thinking of IT as a janitorial cost sink instead of as an investment. any company that can break this mold is going to be light years ahead in the long run, because I have a secret to tell you all... The infrastructure holding most businesses up is set to crumble at the slightest puff o wind, whether that wind be legal, like a lawsuit or an audit, or technical like an internal data breach...
deleted 9y ago
[deleted]
dayjah 9y ago
I’ve always found the metaphors around Technical Debt really interesting. They simplify it to a point where everyone “gets it”; however I have often worried whether there’s a cult of “anti-technical-debt”, much like there are the cults of “absolutely no credit card debt / usage ever”. Sure, it works for some, but I’ve also seen product progress completely halt over the argument of “that’s adding to our technical debt”, surely it would be phrased better as “this is adding to our customers experience, at the cost of our chase for purity and technical perfection”? As has been said a few times in this thread: there’s nuance to engineering, and a careful trade off. I think the metaphors are weaponized to a point where that nuance is lost in harsh memories of student-era credit card debt.
- deleted 9y ago
  [deleted]
ksk 9y ago
We hear a lot about it, but how many people have actually been successful in avoiding technical debt? Any links to writeups/blogs/analyses?
s73v3r_ 9y ago
Technical Debt, like actual debt, is neither a good nor bad thing. The problem is when you have the wrong amount of it.
gowld 9y ago
"Bad code isn’t Technical Debt, it’s an unhedged Call Option" http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...
OnlyRepliesToBS 9y ago
Debt is great until 1929.
skolos 9y ago
Financial debt - you can see a number and make judgments if you have too much of it or too little. How do you measure technical debt?
monksy 9y ago
This is one of those things I don't understand about about software engineering and developers lacking professionalism. Articles and handwavy comments tend to dismiss technical debt as a shrivelling pesky geek who keeps waxing on about how vi is better than emacs. (Someone who doesn't have a lot of influence, nor as important). Pushing techincal debt to be managed by the PO, Scrummaster, busuiness, and/or managers creates major concerns and problems with what you're producing. The passive agressive response: "well convince them" is naive and wrong. They don't care. If we've seen anything from the experiences below, they just end up hoping those days won't come. Examples: 1. Experian- I'm fairly confident that they had at last one engineer there that bitched about how much the dependencies were falling behind. If they have good ones, there would have been talk about how to automate that process. 2. Half baked products/data loss bugs - (See mongo) 3. Frequent "redesigns of projects" - There are major companies out there that have had to redo their entire product range due to this. It can't possibly be affordable. I'm sure theres lot's of lessions on the migrations. But it's a lot more expensive in the long run. Side rant: I guess if you believe that you're going to go out of business tomorrw, this is justified. My point: 1. Be a professional developer, get deep knowledge on frameworks 2. Take your time and develop correctly at the start 3. Build experience with engineering, not the latest JS library that ignores experience. 4. Actually give a shit. Venkat Subermanian made a great qoute at one time: Your code quality is a reflection about how you feel about yourself and your coworkers.
- hinkley 9y ago
  Some people want to appear to by high minded as long as it doesn’t inconvenience them. Scapegoating the business is the easiest thing to do. But when push comes to shove they just don’t want to put in the work.
intrasight 9y ago
My org has no system updates during the month of fiscal close, so we spend that month addressing technical debt.
dlwdlw 9y ago
There is a dangerous moral hazard where the people who take out the debt aren't the ones to pay it back though. I've seen quite a few people jump from company to company using roundabout ways of creating success that are actually debt of some form. Then they leave as the success is claimed with their resume showing that once this lynchpin left the team/company fell apart...
ericmcer 9y ago
Programmer morale is another factor in good/bad technical debt. It can be quite enjoyable to take something like three separate implementations of a similar function, combine them, and delete a bunch of duplicate code. On the other hand, it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable. One makes you feel happy and in control, the other makes you feel like everything is falling apart.
- bcbrown 9y ago
  > it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable. I'm doing that right now, and it's great. There's several responsibilities that are all tightly coupled, and I'm pulling them into multiple components. It's requiring a lot of code archeology and reverse engineering of intent, but it's incredibly satisfying at the end.
deleted 9y ago
[deleted]

163 points by treyhuffine 9y ago

I've often thought that what software projects need is some equivalent of a balance sheet and P&L report - "assets" and "liabilities" together with "income" and "expenditure" equivalents. Looking at technical debt in isolation and always regarding it as a bad thing always seemed simplistic to me.

humanrebar 9y ago
Agreed. I've seen teams use no metrics. And I've seen teams use one or two metrics. I haven't seen management deal with complexity like a professional analyst for a pro sports club would: with a range of different metrics to inform human judgements.
- sharemywin 9y ago
  That's because it's just a way for tech people to sell work, that shows no immediate benefit to the business, to accountants, who sign the checks, that don't like debt.
- noxToken 9y ago
  How do you measure complexity with an objective number? I have a few ideas for what could go into it for a given task or process (number of branching paths, number of methods called, LOC, time to develop, etc.) but how do you assign weights to these?
  - humanrebar 9y ago
    > ...how do you assign weights to [metrics] To start with, you don't. Baseball managers and scouts look at a lot of metrics: runs, hits, walks, OBP, VAR, number of pitches in a career, convicted felonies, etc. But at the end of the day, there are people making judgement calls. They're just, ideally, exceptionally well-informed people. So what I'd like to see, at least initially, is a healthier universe of metrics we can automatically grab from code bases. Deciders can set up dashboards or reports for those as needed. There would still be actual conversations and decisions involving actual humans, but they'd be looking at this data as they're having qualitative discussions about their options.
  - dllthomas 9y ago
    https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity (relevant, not a complete answer by any stretch)
- s73v3r_ 9y ago
  What would those metrics be?

humanrebar 9y ago

Sure, and credit cards can be a good thing, too. The problem is that most non-technical and formerly-technical project managers just charge everything to their credit cards and don't even know they own debt and are making interest payments on it. When that's the level of awareness the average development team is dealing with, there's limited practical purpose in exploring the nuances of healthy debt management. It's more useful to talk about technical debt like nutritionists talk about empty calories and transfats.

allyjweir 9y ago
I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those. The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.
rebeccaskinner 9y ago
I see accusations of this a lot, and honestly I just really wonder what the team structures are like at a lot of companies- or what the experience level is of the average HN reader. Because you're right, PMs don't have the insight to understand the nuances of technical debt and the benefits and costs associated with varied approaches, and really it's not their job to. As technical folks, it's our job to learn how to say "no", and not just in an abrasive way that shuts down the conversation, but to work with project managers and decision makers, understand the reasons for their decisions, and push back firmly but using language that they can relate to and speaking to their problems. Regardless of how much PMs might want things or fiddle with the schedule, as professionals it's our job- not theirs- to say when things can't be done, shouldn't be attempted, or might cost more than they're worth.
- snarfy 9y ago
  You must be an expert[1] [1] - https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg

nautilus12 9y ago

I'm starting to see a trend in hacker news stories of the type: Why bad for you thing is actually good for you. or Why thing everybody likes is not so great after all. Is everyone on hacker news just a compulsive contrarian?

humanrebar 9y ago
We read "man bites dog" stories, not "dog bites man" stories. Exceptions are inherently more newsworthy.
- yen223 9y ago
  The danger is that readers may be led to believe that the exceptions are the norm.
sharemywin 9y ago
I would have to disagree
reificator 9y ago
> Is everyone on hacker news just a compulsive contrarian? No we're not.
- nathan_long 9y ago
  I am!
  - your-nanny 9y ago
    Yes, possibly maybe. Oh never mind.
    - cirgue 9y ago
      I disagree with you, though I am not sure where that puts me.

fimdomeio 9y ago

Best part is the narration and how Mr. computer says a lot of "undefined" in the middle of the text. :love

allyjweir 9y ago

From my recent experience in a new team, this article strikes a chord. Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily. We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.

wes-k 9y ago
"premature optimization is the root of all evil" - Knuth
bpicolo 9y ago
I'd argue that "simple, clearly tested" code is the antithesis of technical debt anyway.
spdionis 9y ago
> making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily I would say that's just bad engineering due to lack of insight or experience. DRY is the most simple and most dangerous principle (or "best-practice") of them all, because when it goes wrong it's the one that hurts the most.
- allyjweir 9y ago
  Yes I agree. Bad engineering led them to not accepting the reality that technical debt is unavoidable. In a misguided attempt to avoid it, they overengineered ironically leading to more debt than might otherwise have accrued.
wvenable 9y ago
> For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily. That's just another form of technical debt. Over-engineering is also a well known cause of debt accumulation.

zeroxfe 9y ago

Managing technical debt is one of them most important parts of engineering. When you're resource constrained, which is almost a given in the real world, you need to think carefully about what kinds of debts are worth accruing, and what kinds are absolutely not. I think this is both an art and a science, and the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture. There are so many factors involved that it's not surprising so many projects accrue horrible debt.

raverbashing 9y ago
Also, some debts are not even debts, but normal limitations of the code If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt
- Cthulhu_ 9y ago
  It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.
  - beersigns 9y ago
    Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.
    - aldanor 9y ago
      Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).

candu 9y ago

Information presentation nit: did anyone else find those "mental model" diagrams really hard to parse? (Especially the first one.)

bloudermilk 9y ago
Agreed, skipped over these. The rest of the content was golden.

bandrami 9y ago

That's a decent argument for bottom-up programming. Though I'd also say what's really at issue here is short term vs. long term technical debt. Writing software bottom-up front-loads some short term technical debt but leaves you much better able to avoid long-term technical debt because you have a much more flexible product.

blauditore 9y ago

There's a fine line between iterative development ("first do it, then do it right, then do it fast") and actual technical dept caused by bad practices (e.g. copy-and-edit instead of re-use). The former method is well-aware of shortcomings and heading towards eliminating them eventually, so I'm not sure if it should even be called technical debt. Actual technical debt (like real life debt) has the problem of "interest" attached to it, so it grows exponentially. So if you're not constantly working to reduce it, it may grow out of hand quickly.

bloudermilk 9y ago

Fantastic article. As an engineering manager working for a lot of young startups, I’ve found technical debt to be inevitable. The author seems to have come to the same conclusion I have: embrace technical debt by leveraging it conciously and tracking it carefully.

paulie_a 9y ago

Technical debt is a debt that someone else will have to pay off. My greatest accomplishment at my current job has been deleting 45K-60K lines of code. Not every bit of code will be perfect for many reasons, but please be thoughtful at least, and not just hammer out code. Someone else is going to have to clean up your mess.

endorphone 9y ago
On the flip side, be thoughtful that your job exists because that code was hammered out. I've created loads of technical debt over my career, in the process literally creating whole product lines that later became the career home for teams of people.
ozim 9y ago
Funny thing is that technical debt is not like money debt. There is a lot of possibilities that this debt will just be deleted, obsoleted, project discontinued. So it is more like survivorship bias, you only get to fix debt that is still alive. Debt that went away and no one is ever paying it is nowhere to be seen.
- PeterisP 9y ago
  Bankruptcy is one way to erase debt, and the most horrible debts go out that way. So it's like survivorship bias, where the most important technical debt (the one that kills its project) is often not noticed.

j45 9y ago

Technical debt can benefit from being managed in it's own category - it's inevitable as bugs and features. Unmanaged technical debt is sometimes the 'bad' technical debt we think and read about in hindsight. When I'm a little more aware of technical debt being created - I track and manage it just like a feature or a bug in the project management system. Separate type, label or category of ticket. It surprising several tools don't have this out of the box for some reason. There's a few benefits to technical Debt being categorized separately: Tracking technical debt helps provide a sense of the technical debt tickets that are being opened, and floating around both in numbers, size and unknowns. Keeping technical debt items tracked along side features, and bugs in it's own category is an invaluable form of cross-training to new team members who are learning the why the current code base came to be how it is, and not just what they may see or think is best. We see how good we might be as a team and individually at identifying technical debt, and if we are improving at identifying it, and help develop a ratio for future accuracy. Regular technical debt review helps create a sense of what technical debt is occurring, and what can be fixed under the hood on another project, if desired, or possible. Keeping an eye on technical debt is important too, if something initially small is at risk of painting the project into a corner, or becoming exponentially difficult to re-factor. Would love to hear strategies and tactics you might use in your TD practice.

convolvatron 9y ago
even if its not timely to implement - design the replacement right away, and update it if necessary. this helps scope the work, understand what other components are being effected, and allows related systems to be written with an eye towards the fixed version instead of the damaged one.
- j45 9y ago
  That's a really good idea. We make the technical debt ticket anyways describing the problem, taking a few more minutes to describe "how it should be" so a design process can begin... it will be much easier to pick it up later on... maybe even tie it to an ongoing Technical Debt Roadmap that can be tied into the main product roadmap.

nwhatt 9y ago

A lesson I learned early in my career was to avoid spinning out too much on why a particular piece of code someone else wrote was so “bad”. The metaphor in this article fits perfectly- the developer who wrote this borrowed from the future, and without being there at the time, I can’t really judge their calculations.

taneq 9y ago
Also, ugly code that solves a problem for your customers is worth more (ie. is more 'good') than pretty code which doesn't. Customers don't care what the back-end looks like, they just want their problem solved, and pretty code never increased revenue.

skrebbel 9y ago

I'd say that technical debt is often the best kind of debt you can take on as a startup. Difficult to maintain code is not going to be the thing that puts you out of business. Usually that's making the wrong product or not being able to reach your market. Compare that to the other kinds of debt (convertible, for instance). They cost a lot of time to obtain and, potentially, a lot of money in the long run if you do well. Many of the most successful startups had (have?) shitty code. Of course there's great counterexamples (i.e. WhatsApp having a 5 person backend team when they were acquired), but as a programmer and founder I find that my urge to make shitty code and ship fast is waay smaller than my urge to make fantastic beautiful code. Of course shipping fast does not imply writing crap code in general. At all. But sometimes it does, and when it does, I've learned that hard way that maybe it's better to choose the crap code.

marcosdumay 9y ago
How often being unable to change your code is the cause of bad product-market fit? How does needing 40 people instead of 5 to run your infrastructure compares with the carry cost of monetary debt? If you were only arguing that the people around here probably needs to be more open to technical debt because we here are mostly perfectionists I would probably agree. But I don't think I can agree with most of what is your post.
- skrebbel 9y ago
  By the time we can afford to pay 5(!), let alone 40 people to run our infrastructure, I don't think you can call us a startup anymore. This is my point exactly. Until you've found product market fit, the size of the infrastructure team "once you're big" should be the least of your concerns. Personally I don't understand how any tech company with a 5+ person infrastructure team can still be called a startup (unless the infrastructure is the product ofc, eg if you're a PaaS or something)

mikekchar 9y ago

I'd like to quibble a bit with the definition of technical debt being used. A decision not to refactor code when you don't know if you will be improving it is not technical debt in my book. There are many times when I look at a piece of code and say, "This is a smell here, but until we know better what we are building I can't remove the smell". It actually would be technical debt if I covered up the smell with something pretty that wasn't related to what I actually needed. Later on I'll have to remove that pretty code (or work around it). Hopefully making me feel better about apparent lack of smells is worth it ;-) The idea of technical debt is that you are trading some kind of completeness/correctness in the code for something else that is valuable. Usually that valuable thing is time, but it can be something else. For example, perhaps you know that your requirements are wrong. However, the client is unhappy with answering questions. You could pester them some more, or you could implement the obviously wrong requirements and wait for them to find the problem themselves. In this way you defer the frustration of your client to a later time when they might be more approachable. It should go without saying that you should almost never do the above: I'm only using it as an example of tech debt that isn't to do with saving time. There are lots of times where technical debt is beneficial. The key is to understand the cost/benefit. This is where we usually go wrong. The cost/benefit analysis is usually done by someone who only understands the benefit. It's just making the analysis of borrowing money and making the assumption that you don't have to pay it back. Hmm... how much money should I borrow in that case? Obviously, as much as I can get!

snowwrestler 9y ago

I think this is just another way of saying "avoid gold-plating." Building a new service to stand up to millions of users and nation-state attackers is probably overkill until you know whether anyone actually wants it. That said, there are definitely early technical decisions that will be very painful to change later on, like how you authenticate users and protect PII.

Drdrdrq 9y ago

There are different kinds od technical debt. One should aim to keep abstractions simple, and to be able to refactor as quickly as possible. But that also means that the code should be manageable. Unreadable code is never a good thing, and will slow down development considerably.

sdmadf2834 9y ago

"Technical Debt is most of the time used as a negative connotation, but it doesn't need to be like that all the time. It's like taking a loan. It will allow you to deliver software faster in adverse circumstances without having to invest enough time to find the best design for a problem." Lol yeah, taking out a loan for all your future hires to pay back later.

davidhyde 9y ago

"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it?" In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design."

coldacid 9y ago

A far better title for this article, given the content, would have been "How to Manage the Inevitable Technical Debt of your Projects".

davidhyde 9y ago

"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it? In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design." I found the article excellent and I like the financial debt metaphor a lot. However, the quote above is somewhat confusing. I usually get rid of technical debt (post task) so that a developer can read and understand the code better. They need to do this in order to make some future unknown change. Since a "better design" would at least involve understanding the current design then a strongly disagree with leaving technical debt in code you do not think will be touched again.

toss1 9y ago
While it's excellent to make the code readable for the next guy, I read this as talking about the architecture level, where reading the code will be largely unnecessary because it is all junked for Rev.2 I did this for one SAAS company and it worked out great. Although I had been very much a design-everything, pre-optimize excessively type of coder/designer, for this project at a company I co-founded I went completely the opposite direction. With only a slight nod to the architecture I expected we'd need later, I just coded up the first version in the easiest high-level tools we had, separating only one module. This allowed us to get a much better handle on the actual requirements, especially since the marketing guys of course went out and sold some of the prototype. Fortunately the sales were small enough that we didn't get swamped, but it gave me real data, and strongly reinforced my plan to build a highly modular set of interacting services such that each could run on separate hardware, which could also be scaled in hours. This very scaleable architecture later allowed us to take business from competitors who were (AFAICT) were stuck in a monolithic architecture. But after the first version had served it's purpose, no one has ever read any of the code again in the 15 yrs since. We just started on the main version and never looked back. So as a person who formerly would have recommended the opposite, I can strongly recommend making a really brief Plan A prototype / first version that you plan to throw away. Just make sure that you do actually throw it away, and soon (code that sort-of works does have a way of sticking around too long).
- davidhyde 9y ago

arca_vorago 9y ago

I know most here are focused on the dev side of things, but coming from the sysadmin side where I've had to deal with the technical debt of devs + the entire rest of the business IT technical debt, it is anything but good. I've seen the insides of hundred of companies, and the number one cause of technical debt is lack of proper manpower to work ratios. Usually due to short term thinking of IT as a janitorial cost sink instead of as an investment. any company that can break this mold is going to be light years ahead in the long run, because I have a secret to tell you all... The infrastructure holding most businesses up is set to crumble at the slightest puff o wind, whether that wind be legal, like a lawsuit or an audit, or technical like an internal data breach...

deleted 9y ago

[deleted]

dayjah 9y ago

I’ve always found the metaphors around Technical Debt really interesting. They simplify it to a point where everyone “gets it”; however I have often worried whether there’s a cult of “anti-technical-debt”, much like there are the cults of “absolutely no credit card debt / usage ever”. Sure, it works for some, but I’ve also seen product progress completely halt over the argument of “that’s adding to our technical debt”, surely it would be phrased better as “this is adding to our customers experience, at the cost of our chase for purity and technical perfection”? As has been said a few times in this thread: there’s nuance to engineering, and a careful trade off. I think the metaphors are weaponized to a point where that nuance is lost in harsh memories of student-era credit card debt.

deleted 9y ago
[deleted]

ksk 9y ago

We hear a lot about it, but how many people have actually been successful in avoiding technical debt? Any links to writeups/blogs/analyses?

s73v3r_ 9y ago

Technical Debt, like actual debt, is neither a good nor bad thing. The problem is when you have the wrong amount of it.

gowld 9y ago

"Bad code isn’t Technical Debt, it’s an unhedged Call Option" http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...

OnlyRepliesToBS 9y ago

Debt is great until 1929.

skolos 9y ago

Financial debt - you can see a number and make judgments if you have too much of it or too little. How do you measure technical debt?

monksy 9y ago

This is one of those things I don't understand about about software engineering and developers lacking professionalism. Articles and handwavy comments tend to dismiss technical debt as a shrivelling pesky geek who keeps waxing on about how vi is better than emacs. (Someone who doesn't have a lot of influence, nor as important). Pushing techincal debt to be managed by the PO, Scrummaster, busuiness, and/or managers creates major concerns and problems with what you're producing. The passive agressive response: "well convince them" is naive and wrong. They don't care. If we've seen anything from the experiences below, they just end up hoping those days won't come. Examples: 1. Experian- I'm fairly confident that they had at last one engineer there that bitched about how much the dependencies were falling behind. If they have good ones, there would have been talk about how to automate that process. 2. Half baked products/data loss bugs - (See mongo) 3. Frequent "redesigns of projects" - There are major companies out there that have had to redo their entire product range due to this. It can't possibly be affordable. I'm sure theres lot's of lessions on the migrations. But it's a lot more expensive in the long run. Side rant: I guess if you believe that you're going to go out of business tomorrw, this is justified. My point: 1. Be a professional developer, get deep knowledge on frameworks 2. Take your time and develop correctly at the start 3. Build experience with engineering, not the latest JS library that ignores experience. 4. Actually give a shit. Venkat Subermanian made a great qoute at one time: Your code quality is a reflection about how you feel about yourself and your coworkers.

hinkley 9y ago
Some people want to appear to by high minded as long as it doesn’t inconvenience them. Scapegoating the business is the easiest thing to do. But when push comes to shove they just don’t want to put in the work.

intrasight 9y ago

My org has no system updates during the month of fiscal close, so we spend that month addressing technical debt.

dlwdlw 9y ago

There is a dangerous moral hazard where the people who take out the debt aren't the ones to pay it back though. I've seen quite a few people jump from company to company using roundabout ways of creating success that are actually debt of some form. Then they leave as the success is claimed with their resume showing that once this lynchpin left the team/company fell apart...

ericmcer 9y ago

Programmer morale is another factor in good/bad technical debt. It can be quite enjoyable to take something like three separate implementations of a similar function, combine them, and delete a bunch of duplicate code. On the other hand, it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable. One makes you feel happy and in control, the other makes you feel like everything is falling apart.

bcbrown 9y ago
> it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable. I'm doing that right now, and it's great. There's several responsibilities that are all tightly coupled, and I'm pulling them into multiple components. It's requiring a lot of code archeology and reverse engineering of intent, but it's incredibly satisfying at the end.

deleted 9y ago

[deleted]