15 ms·

Three Kinds of Good Tech Debt

426 points by memset 7y ago

halfmatthalfcat 7y ago
As I’ve gotten more senior in my career, I think one of the most enlightening things has been anticipating debt before it happens (in planning/architecting), acknowledging it when it does and then taking prudent measures to minimize it and log it for future refactoring. It’s also been funny seeing managers try to rebrand tech debt with other business speak like “tech health”. Debt shouldn’t be a bad thing but one that’s anticipated and respected.
- GeneralMayhem 7y ago
  "Health" of a system isn't synonymous with debt. It's what happens when debt isn't respected and becomes bad. Debt is a tool; health is a state. If you carry six months of salary as credit card debt,a financial advisor isn't going to talk about how you're using debt as a tool, they're going to talk about your "financial health".
- ThePadawan 7y ago
  The term "debt" is really helpful. It also explains that while you can pay off debts by taking on other debts, there is a good reason why this is illegal (if done with money) in the real world. Technical debt in your solution is fine. Running a Ponzi scheme in your solution isn't.
  - isostatic 7y ago
    > while you can pay off debts by taking on other debts, there is a good reason why this is illegal Loan consolidation is quite normal in the UK
    - ThePadawan 7y ago
      Sorry, I was mentally adding "without the consent of both parties". Because otherwise, what would stop you taking on a loan for X, then paying it off after a while by taking on the same amount from another bank?
      - pbowyer 7y ago
        > Because otherwise, what would stop you taking on a loan for X, then paying it off after a while by taking on the same amount from another bank? Nothing. That's why lenders do credit checks and due diligence.
      - lazyasciiart 7y ago
        Absolutely nothing stops you. The bank you owe money to has no rights whatsoever to control where the payoff money comes from. https://www.moneycrashers.com/responsible-use-0-balance-transfer-credit-cards-debt/ https://www.moneycrashers.com/responsible-use-0-balance-tran...
        dredmorbius 7y ago
        The bank lending the money may we'll care where it's going. A bank's primary business is managing risk. And borrowing from Peter to pay Paul (having previously borrowed from Paul) is a significantly different risk profile than borrowing for investment or even present consumption.
      - jeremyjh 7y ago
        In business/commercial lending the purpose of the loan is typically a part of the contract. You can’t say you will use the money to buy equipment and then use it to pay off another debt. Also you will have to provide regular (yearly/quarterly) financial statements (typically audited) that include a balance sheet that would list all outstanding debts and assets. As long as you abide by all your existing and future loan covenants you certainly can use loans to pay off debt and many people do. When you can’t it’s due to contracts, not “laws”.
  - dspillett 7y ago
    > there is a good reason why this is illegal (if done with money) in the real world. Erm, it very much isn't illegal. At least not in most places. Taking on fresh debt to pay off other debt is the very definition of a consolidation loan which is perfectly legal in most, possibly all, jurisdictions. There are limits of course, like not using a loan to pay the deposit on a mortgage, or simply not lending beyond defined means, but these are set by the bank to manage their own exposure to risk rather than limits set by law. Such limits are merely encouraged by law, via regulatory limits on standing capital compared to debt held and so forth.
    - joshlegs 7y ago
      also basically any 'balance transfer' option on pretty much every credit card ever.
    - Gibbon1 7y ago
      In the brick and mortar world rolling debt is common.
  - notabee 7y ago
    I think debt is also useful for the interest metaphor. An unfinished kludge by itself may not be very expensive to fix up and change, but if that kludge doesn't change and becomes a dependency in a complex environment it is likely to become much more painful to fix later.
- ebiester 7y ago
  Managers rebrand because their bosses and non-technical people start ignoring a term once it's used long enough, so we have to market it in another way. There's also a distinction between "we made intentional decisions that we need to fix up now" and "We (or people before us) made unintentional decisions and it is in such a bad state that it endangers the health of the business."
- Jestar342 7y ago
  I've also come to realise that technical debt is everything. Anything that is resistant to change is technical debt, which includes the code you are writing "now", whether you anticipate its need to change in the future or not. There's the stuff that you know is painful or messy, but then there's the stuff that is suitable for today's needs but those needs may change in the future. Nothing is free from debt.
nicoburns 7y ago
I'm not sure if I'd even consider these things tech debt. I tend to distinguish between: 1. Unfinished/unpolished implementations 2. Implementations that are architectural flawed, such that fixing them requires throwing away the existing code. Issues in (2) are a lot more problematic than issues in (1).
- mbostleman 7y ago
  Yea, I was going to say the same thing. Work undone as part of prioritization is not debt. Debt to me is causing more work than it would take otherwise so that less work can be done now (or because the developer / architect just doesn't know any better). Using a switch statement instead of a factory. Using role based auth instead of attribute based. Things like that. The problem is, the debt metaphor is not being applied correctly. Not doing future work now does not take on responsibility for the future work - so it's not like taking a loan. Doing work in a way that commits the team to extra work that didn't exist before - that's like taking on a loan. For instance, I don't want to do this 80 points of work now, so I'm going to ship the same requirement by doing 40 points of work on a solution that will take another 60 points to get to the original 80 point solution which is the way we know we have to go long term. I just borrowed 20 points on behalf of the team.
julianozen 7y ago
Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.
- stronglikedan 7y ago
  > I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. IMHE, it's usually management that feels this way.
- human20190310 7y ago
  It's also great that the author gave concrete examples of times where it made sense to eschew purity for pragmatism. Very good article all-around.
- BurningFrog 7y ago
  > I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!
  - jackcosgrove 7y ago
    Maybe programmers need to listen to Marie Kondo more.
    - the_seraphim 7y ago
      does this for loop make me happy?
    - yboris 7y ago
deleted 7y ago
[deleted]
losthobbies 7y ago
Nice article. The code review articles are good too: https://engineering.squarespace.com/blog/2019/code-review-culture-part-1 https://engineering.squarespace.com/blog/2019/code-review-cu... https://engineering.squarespace.com/blog/2019/code-review-culture-part-2 https://engineering.squarespace.com/blog/2019/code-review-cu...
stevetodd 7y ago
I prefer the definition of technical debt being an uncovered call option: at some point the debt will come due and you don’t have anything in place to mitigate the issues it will cause and may not know when it will come due. This debt might look like a manual deploy process, a lack of automated testing, insufficient alerting, no rate limiting on public endpoints, etc. These are things that are fine and then when they’re not, they interrupt the schedule and require urgent and immediate attention. Bad architecture can cause urgent issues and it can also impact new feature development. The debt is a barrier that makes new features either take much longer than they should or make them just infeasible from a business standpoint. This can exist in both technical architecture or information architecture (i.e. you chose the wrong model and now it’s too engrained across everything to change).
dsjoerg 7y ago
Another kind of good tech debt I was hoping to see here is when something is built somewhat poorly/quickly because it will give you information that you need to have in order to know whether it's worth building it any better.
- notabee 7y ago
  Prototypes are very valuable as long as you know to throw them away and build the real thing. The unfortunate aspect of many business environments is that low knowledge outsiders see something "working" and demand that it be thrown into production for [insert business speak reasons]. Tech debt isn't always a decision made by the subject matter experts.
- wool_gather 7y ago
  I thought that was exactly the kind mentioned first: > We realized we could build something cheap that we didn’t mind throwing away later—scaffolding—to unblock getting user feedback sooner. If not, can you say more about the difference? I'm interested.
jakozaur 7y ago
Tech debt is inevitable and is good as long as you keep the level of debt reasonable, so maintanance cost doesn’t sunk too much of your dev time. More good examples: 1. Technology progress: Long time ago JQuery was the best for UI library. Today you would use React or friends. 2. Company stage. As a early startup you usually prioritize for speed and validating hyphothesis. As you got a significant user base quality matters more. 3. Size of development team. With 5 or less developers having a monolite is good enough. With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster.
- jackcosgrove 7y ago
  > 3 I think it's almost part of most companies' lifecycles that they start with a monolith, and anticipate rebuilding it as microservices if they get traction.
- purple_ducks 7y ago
  > With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster. Microservices aren't magic. There still has to be a contract between the services. Microservices are best when they are something which need to be scaled independently of the rest of the system.
Shinchy 7y ago
> Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! We do say Congratulations! - we say well done on finishing the project you were working on. I do agree with the part on not putting too much worth on edge cases, however the biggest issue for me with Technical Debt is the increased time it often leads to in further development. So I wouldn't say it's something to completely ignore.
sorokod 7y ago
So we asked ourselves, “What’s the simplest thing that would make the editor useful to our coworkers?” To me, technical debt is associated with a sense of regret. The example in the quote above doesn't have that, perhaps that is what makes it the good kind.
- wellpast 7y ago
  Perhaps this isn't "Tech Debt" at all. Perhaps this is a long understood, well-known activity called Prototyping or Learning. Perhaps the concept of "Tech Debt" is just fuzzy thinking.
  - sorokod 7y ago
    Yes, something like that. When a suboptimal solution serves a strategic purpose it is not TD.
    - deleted 7y ago
      [deleted]
wellpast 7y ago
I'm going to take a more controversial position here, and it bothers me that it is even controversial. The very concept of Tech Debt, though prevalent, is pernicious, because its a concept that is far, far, far too fuzzy and therefore can -- and is -- always applied as a convenient narrative to explain away mistakes, process deficiencies, bugs, etc rather than a true conceptual problem-solving tool that aids in optimizing the software development process. In short, "Tech Debt" is a euphemism for incompetence. We can see this play out in this post, which covers "3 kinds of good tech debt. 1) "Scaffolding" ... what the author describes here is good ol' fashion Prototyping, aka Learning. No invocation of a fuzzy concept like "Tech Debt" is needed here. You don't know something, so you go and learn what you need to learn. Learning takes many forms. In this case, it is product understanding -- and this author reaches for prototyping in particular and calls it Scaffolding. Why a new term? Why obfuscate, why fuzzify? Because that's what Tech Debt is good for: fuzzy thinking. If we move to more clarity we can be specific and we can take specific actions to optimize: here, maybe or maybe not prototyping isn't the most efficient way to learn what is needed: often, wireframes shown to customers will suffice. There are plenty of ways to skin this once the framing is clear. 2) "Hardcoding" Again, no fuzziness is needed here. Developers have a fetish for fully flexible and feature-rich subsystems and we tend to call anything else a pejorative like "hard-coding" but that's a psychological problem in us, not a technical or process problem. We already have a clear framework for talking about this and it's called feature Scoping. There are, again, plenty of ways to skin this cat, but the short of it is - if you can understand what features you are interested in with clarity then you can build a system whose flexibility is in accordance. This isn't a fuzzy "Tech Debt" thing. If you only need feature X now and going forward, then build that - and call it something pejorative like "hard coding" if you want: I call it being rational. But bringing in a fuzzy term like "Tech Debt" helps nothing here. Only confuses. 3) "Not Fixing Edge Cases" This one is the worst of all. By using a fuzzy term like "Tech Debt" we're able to completely alleviate our responsibility. And start down a path of extreme cost and pain. Here, he wants to avoid having to implement correctness because it would cost too much. The example is a good one: it reflects a pattern I've seen over and over again. And unfortunately I've seen the same choice this author makes -- and the terrible downstream cost it creates, as well. By avoiding implementing a correct solution (by purposefully shipping a race condition) he is not being clever, he is being irresponsible. If this sounds draconian, let me explain further. Perhaps he finds, as he mentions, that in production this is inconsequential. Okay, great. But first thing to point out is that most likely it will become an issue as the system grows and when are you going to notice that? Are you going to go build monitoring to make sure that this "effective correctness" holds over time? Of course not, that's more work. But even if you are happy with his choice here, there's a bigger issue. He has chosen to build a system with transactional needs on top of an eventually consistent/NoSQL solution. From my experience, it's rare that you have just one feature like his that needs transactional correctness and that is it. Tomorrow, next week, soon--he and his team are going to find out that they need another transactional capability and then they are going to be right back where they started: having to ask a question, do I slack off here, as well? Again -- we've created cost for ourselves by forcing us to ask, should I ship a bug in this case? One might say this is what "Tech Debt" lets you do! It lets kick the can down the road, save you some time now... But I do not buy it. I've seen this exact kind of choice made plenty of times and the can always comes back next week, next month and the tax you pay for not getting right is immense. "Tech Debt" here is simply letting us avoid responsibility, avoid having to understand the needs of our overall system. The cost of getting transactions right/correct is not even that high if you face it squarely and truly make sure you need NoSQL and in which cases. What's happening here is not clever process optimization but inexperience. And if not inexperience, laziness (not the good kind). The concept of "Tech Debt" is awful. And always ends up being a euphemistic excuse. I've never seen the idea of "Tech Debt" help the actual process and technical quality of things. I've only ever seen it give developers an excuse for inexperience, laziness, etc. I don't mean to denigrate here -- I mean to challenge and ask for us to be more intentional, clear, and frank in our work. "Tech Debut" is fuzzy thinking and fuzzy thinking isn't much good for anything other than excuses.
nerpderp82 7y ago
If you aren't spending tech debt, you don't have a sound monetary policy. Zero tech debt is not a healthy goal.
- wellpast 7y ago
  Unlike financial debt, which has a clear quantitative measure, Tech Debt is an incredibly fuzzy concept to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.
  - Raidion 7y ago
    But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it. Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your systems will almost always have limitations, it's important to understand these and communicate them well. Tech debt should be managed so it doesn't tip over and cause issues. Really good devs and dev managers develop the eye to see when that's about to happen and make sure they convince product that you need to pay that down soon.
    - wellpast 7y ago
      > Is it worth implementing a cache layer in a system? This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my system need to handle 1M concurrent users? If so, support that. If not, don't support it. But we don't need the absurd concept of "Tech Debt" for effective analysis. We can be specific. We can be clear. Does my system need to support low latency in the face of 1M concurrent users? Yes or no. Now proceed. "Tech Debt" is such a ridiculous dodge to otherwise avoid real analysis, real work, real clarity.
      - aeorgnoieang 7y ago
enginaar 7y ago
I'm failing to see the point in calling a technical dept "good". As far as I can tell from the article, the author is measuring 2 possibilities of technical dept and choosing the one that incurs the least dept. I can see how good a decision this is but I don't see how this makes the dept good.
- rockinghigh 7y ago
  It’s tech debt, as in a liability that you will have to pay back on the future.
- kevsim 7y ago
  > I don't see how this makes the dept good Time to market, for one. If you get the feature out faster to your customer, eating some debt can be worthwhile. This article is merely providing a structured way to think about the debt you're taking on.
- weego 7y ago
  Technical debt is a luxury companies with an excess of resources have. Startups without an excess of resources do not have technical debt in that, if you have no more runway and shutter thr business all you have is a bunch of code that didn't justify its own existence. By definition it is a positive situation to be in. So code that you can propose may be technical dept that make your Series A is good debt.
theptip 7y ago
I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves adding tech debt. However, if you're mindful about where you take on tech debt, and commit to tapering and then paying it down as your resources grow, then you're more likely to avoid the debt spiral where your development grinds to a halt, due to everything breaking all the time. One other point I'd make is that a common form of "tech debt" for early-stage startups is simply doing things that don't scale; it's often beneficial to make your domain models flexible so that you can support one-off manual interactions, for example if a new customer appears that requires it. Then automate that thing and constrain the domain actions once you have collected enough use-cases to know what makes sense to forbid.
- WorldMaker 7y ago
  I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy. (Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")
  - 7y ago
_bxg1 7y ago
This is a good take.
cjfd 7y ago
@1: One could also have automated tests instead of scaffolding. @2: Sure, but this it not really technical debt. It is the wise policy of not immediately writing code for the most general case. If one writes several instances of this it would lead to code duplication that would need to be refactored immediately. @3: Careful with this one. The thing is that the thing you call an edge case might have the more proper name of 'bug'. If you deliberately leave in bugs at the time of writing the code it can lead to very difficult to estimate 'stabilization time' at the point where the code is supposed to go into production but is not quite reliable enough. It becomes somewhat difficult to explain if that 'stabilization time' turns out to be months or even as much as a year.
HelloNurse 7y ago
The defining characteristic of technical debt is attempting to avoid paying it, taking shortcuts that create "interest" in the form of increased effort and cost; it's always bad, but depending on timing and costs it can range from a "correct" minimum cost choice (e.g. badly tested truly throwaway code) to a stupid mistake to an existential threat. Technical debt is a close relative of externalization (I save time, you waste time) and of mistakes that result from incompetence rather than from haste and shortsightedness. All three sections of the article, instead, describe healthy planned evolution from a decent provisional product to a better one, with solutions that might be rough but not necessarily bad. In other words, a clickbait title for sound (but maybe unrealistically mature) examples of properly pragmatic project and product planning.
mlwhiz 7y ago
Sometimes going in a Hardcode way is much better than going around in circles to get the perfect code. Saves time and is more intuitive.
ChrisCinelli 7y ago
> Good Tech Debt Is Intentional When it comes to accelerate development in my opinion this is most (80/20) of it.
davnicwil 7y ago
The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that, so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save time and get something shipped, knowing that it will cost you more time than you're saving now to fix it later. But by shipping now, you ensure there is a later, with a product that's out there and being used, a bigger team and therefore adequate time and then some to fix the debt and keep improving the product. Everyone wins. That's the theory anyway. I think mostly where it goes awry in the wild is people forgetting the paying it off part. Part of this deal is you have to pay back your lender - they have to win too. It's just easily forgotten because you're the lender, so the incentives get a bit conflicted, and you'll keep giving yourself more time. But if the lender ultimitely doesn't get paid back and loses, you lose, and it's a bad debt.
- matchagaucho 7y ago
  Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."
  - chris_wot 7y ago
    Michael Feathers said that he doesn’t use the term when working for banks as they don’t see it as a negative term...
- tempestn 7y ago
  > I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.
  - eikenberry 7y ago
    What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?
momokoko 7y ago
I've always believed that "debt" is not a great term for this. Because it does not really apply to financial debt. Financial debt is often repaid simply by bringing in more revenue because of the benefits gained from bringing on the initial debt. The only risk involved in the debt is that there will not be enough money to pay it back later. It is a very predictable and obvious issue. Technical debt is closer to educated gambling. You are taking a risk that the shortcuts you are taking will not pop up and hurt your company before you fix them. You are essentially saying, "We know this is a problem, but we are estimating that it won't hurt us for the foreseeable future". The better analogy to technical debt is investing. You are getting a certain percentage increase in productivity(a dividend or other capital gain) for the (hopefully low risk) gamble that your investment will not have a problem and wipe it out or simply cause significant losses. Developers typically do not like this because when the inevitable few cases of these "investments" turn bad, they tend to be the ones that take on the majority of the blame.
- k__ 7y ago
  To me they even sound the same after you explained them. Not being able to pay back money sounds like the same as not being able to fix bugs.
dredmorbius 7y ago
JS-mandatory text-only blog posts are bad tech debt. https://outline.com/fH9GzD https://outline.com/fH9GzD
deleted 7y ago
[deleted]
onemoresoop 7y ago
I'm not sure how this classifies as tech debt, but in my experience the worst type of tech debt is found in parts of a system that is relied upon and whose business logic has become unmaintainable, is too complex/poorly understood and is not possible to throw away as too many things depend on it. Also usually whose initial creator is long gone, the documentation is conflicting with the code implementation. This kind of debt causes eternal confusion and constantly lowers the productivity of the team. In cases like these, workarounds are created and more tech debt accrues on top of it that is even harder to reason about. Nobody sane can fix a mess like this and the only hope is death of the system or complete overhaul.
munk-a 7y ago
Tech Debt is never good, but it can be acceptable in exchange for a greater gain. So, just like this article's opening: > Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! Except it is universally reviled, no one wants debt - they just accept debt in reasonable quantities as a way to efficiently get things done. I think, in particular, the success of not-quite-agile-but-similar business practices has confirmed this, plan carefully and evaluate business needs, then get it done in a way that's fast and leaves you relatively free of debt - don't plan for everything. So don't get stuck in analysis paralysis trying to build the perfect things - and don't just code with no thought of the future... it's a difficult road to follow.
somesortofsystm 7y ago
No, and no, and no. Just fix it. Repeat until completion.
vinay_ys 7y ago
Nicely done. Good to see an engineering blog acknowledging tech debt openly. I'm with you all the way until the last paragraph which short-changed the conversation a bit. Quoting a few lines to respond below: >> Build things to be easy to throw away and replace; it’ll make your code more modular. One valid strategy to manage debt is to declare bankruptcy or amnesty on debt – that is throw away the code (because this code is no longer needed). In domains where this possible, definitely use it. But in most real-world touching software domains this is not likely possible. >> Good tech debt has clear, well-known limitations. Document these in code comments, READMEs, FAQs, and conversations with the people who’d care. Doing tech debt accounting in a more formal manner is required to intentionally take debt. In the locking example, it is a design debt (not just a code debt). If the debt isn't document well and then it can become a ticking time bomb to be tripped by a clueless developer later.
jboy55 7y ago
Tech Debt, to me, grows with every line of code you write that didn't replace a line of code. Consider how many projects start with the idea, 'I'll rewrite this and get rid of the tech debt'. First, If the original code isn't deleted, you've added to the tech debt. Now every new engineer will need to learn two chunks of code, and every existing engineer will need to support both. Second, unless you've had a major epiphany between the old code and the new code, you're more likely to run into the trap of the first example. Major epiphany's could be, 'wow, we really didn't need all of that extra stuff', or, 'we've duplicated so much code, we should re-organize this all'. I've been at plenty of companies where you have to understand that the Perl code is really old and these components use that, the Mason rewrite was 80% done and is over there, the Next Gen code was in Ruby these components do that. But now, we're embarking on a new Node/React project to replace all of it, finally going to get rid of the tech debt! (Said with no sarcasm)
- theturtletalks 7y ago
  If tech debt is inevitable, what’s the solution? Good internal documentation and rewrites every few years?
  - rickbad68 7y ago
    a practice of constant refactoring..
- qes 7y ago
  And I would say that's an example of when it can be good to purposefully take on technical debt. In my experience there have been plenty of significant refactorings that simply would not have been done if we didn't allow ourselves to get into this state where there is simultaneously an old and a new way of doing something. Especially if it's an area that sees frequent addition - it's not helpful to have people constantly adding code in the old way while off to the side people are trying to create a new way and completely finish switching everything over to it before integrating. Managing risk and balancing other active tasks in the pipeline also push towards integrating smaller pieces over time while multiple ways of doing the same thing exist. But you need to have organizational continuity, which can be rare when everyone is trying to hop jobs for better salary every couple of years.
opportune 7y ago
I think that "Good Tech Debt Is Intentional" is the key point. If you are able to recognize something as technical debt as it is created, you can also more effectively plan for paying it down later, and note what you think the solution would be at a high level. The real issue with tech debt is not that it exists, but that people wait too long to pay it down, and then end up taking more dependencies/making more technically bad decisions to deal with the tech debt which just makes it even harder to fix.
jdance 7y ago
I take a chance and say it right out: Fix some kind of image library functionality! As a customer who's also used Wordpress (everyone?) its just madness that I have to keep originals on disk somewhere to post it onto another page. I can hardly figure out how to download the full size original to be able to upload it again. I ask you humbly, please, you have the power to improve my life! If you want me to stay on topic -- this is the worst wasted time debt Squarespace has to me as a customer :) code wise the product is really solid so their philosophy is obviously good!
- deleted 7y ago
  [deleted]
tams 7y ago
Technical debt is a wonderful ally when building prototypes. Imagine you are building a prototype and you are clever enough to only focus on validating an idea. Having this focus you ignore all best practices and maintainability issues you might tend to out of habit. What you are likely to end up with is a functioning application that resists change beyond its original goals. And this is good. It lets you declare technical bankruptcy early enough to avoid painful rewrites on a software that was not meant to exist for long anyways.
- spc476 7y ago
  As long as both sides (developer, management) are aware of this (he says, as his "proof-of-concept" was installed into production directly by his manager with no warning).
anonygler 7y ago
> if now >= NEW_CONTENT_DATE No canary? Tsk tsk.
louwrentius 7y ago
This was an amazing article.
another-dave 7y ago
"Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations!" There's an implicit assumption there that your friend can afford the purchase. If banks did no credit checks & your friends were impulsive & broke you might try to talk sense into them instead. Maybe we need to store PM's technical debt for 10 years and perform a credit check when they say "I don't care, just ship it & we'll clean it up later"!
rkagerer 7y ago
Great article. But the only reason their approach to the "11 item" edge case works is that they manage their own data. So they can monitor and might potentially cull manually if it became necessary (eg. What if the race condition caused more than 11 or a future codechange elsewhere stumbles on it). In a non-cloud product where the cost is higher for a vendor to come verify and fix data, this wouldn't fly.
jkoudys 7y ago
Love love love this article. I'm so tired of hearing lazy, unskilled, disorganized, mismanaged, etc. companies handwave the shit they write as simply being "tech debt". Sticking 50ms waits throughout your code, because you're not good enough to figure out how to actually trigger your action from an event or await something completing isn't "tech debt". Maybe hiring people not good enough to figure it out could be considered that from a higher level.. If we are going to allow the tech debt metaphor to continue, too much of the debt I see is the equivalent of a pay-day loan.

426 points by memset 7y ago

As I’ve gotten more senior in my career, I think one of the most enlightening things has been anticipating debt before it happens (in planning/architecting), acknowledging it when it does and then taking prudent measures to minimize it and log it for future refactoring. It’s also been funny seeing managers try to rebrand tech debt with other business speak like “tech health”. Debt shouldn’t be a bad thing but one that’s anticipated and respected.

GeneralMayhem 7y ago
"Health" of a system isn't synonymous with debt. It's what happens when debt isn't respected and becomes bad. Debt is a tool; health is a state. If you carry six months of salary as credit card debt,a financial advisor isn't going to talk about how you're using debt as a tool, they're going to talk about your "financial health".
ThePadawan 7y ago
The term "debt" is really helpful. It also explains that while you can pay off debts by taking on other debts, there is a good reason why this is illegal (if done with money) in the real world. Technical debt in your solution is fine. Running a Ponzi scheme in your solution isn't.
- isostatic 7y ago
  > while you can pay off debts by taking on other debts, there is a good reason why this is illegal Loan consolidation is quite normal in the UK
  - ThePadawan 7y ago
    Sorry, I was mentally adding "without the consent of both parties". Because otherwise, what would stop you taking on a loan for X, then paying it off after a while by taking on the same amount from another bank?
    - pbowyer 7y ago
      > Because otherwise, what would stop you taking on a loan for X, then paying it off after a while by taking on the same amount from another bank? Nothing. That's why lenders do credit checks and due diligence.
    - lazyasciiart 7y ago
      Absolutely nothing stops you. The bank you owe money to has no rights whatsoever to control where the payoff money comes from. https://www.moneycrashers.com/responsible-use-0-balance-transfer-credit-cards-debt/ https://www.moneycrashers.com/responsible-use-0-balance-tran...
      - dredmorbius 7y ago
        The bank lending the money may we'll care where it's going. A bank's primary business is managing risk. And borrowing from Peter to pay Paul (having previously borrowed from Paul) is a significantly different risk profile than borrowing for investment or even present consumption.
    - jeremyjh 7y ago
      In business/commercial lending the purpose of the loan is typically a part of the contract. You can’t say you will use the money to buy equipment and then use it to pay off another debt. Also you will have to provide regular (yearly/quarterly) financial statements (typically audited) that include a balance sheet that would list all outstanding debts and assets. As long as you abide by all your existing and future loan covenants you certainly can use loans to pay off debt and many people do. When you can’t it’s due to contracts, not “laws”.
- dspillett 7y ago
  > there is a good reason why this is illegal (if done with money) in the real world. Erm, it very much isn't illegal. At least not in most places. Taking on fresh debt to pay off other debt is the very definition of a consolidation loan which is perfectly legal in most, possibly all, jurisdictions. There are limits of course, like not using a loan to pay the deposit on a mortgage, or simply not lending beyond defined means, but these are set by the bank to manage their own exposure to risk rather than limits set by law. Such limits are merely encouraged by law, via regulatory limits on standing capital compared to debt held and so forth.
  - joshlegs 7y ago
    also basically any 'balance transfer' option on pretty much every credit card ever.
  - Gibbon1 7y ago
    In the brick and mortar world rolling debt is common.
- notabee 7y ago
  I think debt is also useful for the interest metaphor. An unfinished kludge by itself may not be very expensive to fix up and change, but if that kludge doesn't change and becomes a dependency in a complex environment it is likely to become much more painful to fix later.
ebiester 7y ago
Managers rebrand because their bosses and non-technical people start ignoring a term once it's used long enough, so we have to market it in another way. There's also a distinction between "we made intentional decisions that we need to fix up now" and "We (or people before us) made unintentional decisions and it is in such a bad state that it endangers the health of the business."
Jestar342 7y ago
I've also come to realise that technical debt is everything. Anything that is resistant to change is technical debt, which includes the code you are writing "now", whether you anticipate its need to change in the future or not. There's the stuff that you know is painful or messy, but then there's the stuff that is suitable for today's needs but those needs may change in the future. Nothing is free from debt.

nicoburns 7y ago

I'm not sure if I'd even consider these things tech debt. I tend to distinguish between: 1. Unfinished/unpolished implementations 2. Implementations that are architectural flawed, such that fixing them requires throwing away the existing code. Issues in (2) are a lot more problematic than issues in (1).

mbostleman 7y ago
Yea, I was going to say the same thing. Work undone as part of prioritization is not debt. Debt to me is causing more work than it would take otherwise so that less work can be done now (or because the developer / architect just doesn't know any better). Using a switch statement instead of a factory. Using role based auth instead of attribute based. Things like that. The problem is, the debt metaphor is not being applied correctly. Not doing future work now does not take on responsibility for the future work - so it's not like taking a loan. Doing work in a way that commits the team to extra work that didn't exist before - that's like taking on a loan. For instance, I don't want to do this 80 points of work now, so I'm going to ship the same requirement by doing 40 points of work on a solution that will take another 60 points to get to the original 80 point solution which is the way we know we have to go long term. I just borrowed 20 points on behalf of the team.

julianozen 7y ago

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.

stronglikedan 7y ago
> I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. IMHE, it's usually management that feels this way.
human20190310 7y ago
It's also great that the author gave concrete examples of times where it made sense to eschew purity for pragmatism. Very good article all-around.
BurningFrog 7y ago
> I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!
- jackcosgrove 7y ago
  Maybe programmers need to listen to Marie Kondo more.
  - the_seraphim 7y ago
    does this for loop make me happy?
  - yboris 7y ago

deleted 7y ago

[deleted]

losthobbies 7y ago

Nice article. The code review articles are good too: https://engineering.squarespace.com/blog/2019/code-review-culture-part-1 https://engineering.squarespace.com/blog/2019/code-review-cu... https://engineering.squarespace.com/blog/2019/code-review-culture-part-2 https://engineering.squarespace.com/blog/2019/code-review-cu...

stevetodd 7y ago

I prefer the definition of technical debt being an uncovered call option: at some point the debt will come due and you don’t have anything in place to mitigate the issues it will cause and may not know when it will come due. This debt might look like a manual deploy process, a lack of automated testing, insufficient alerting, no rate limiting on public endpoints, etc. These are things that are fine and then when they’re not, they interrupt the schedule and require urgent and immediate attention. Bad architecture can cause urgent issues and it can also impact new feature development. The debt is a barrier that makes new features either take much longer than they should or make them just infeasible from a business standpoint. This can exist in both technical architecture or information architecture (i.e. you chose the wrong model and now it’s too engrained across everything to change).

dsjoerg 7y ago

Another kind of good tech debt I was hoping to see here is when something is built somewhat poorly/quickly because it will give you information that you need to have in order to know whether it's worth building it any better.

notabee 7y ago
Prototypes are very valuable as long as you know to throw them away and build the real thing. The unfortunate aspect of many business environments is that low knowledge outsiders see something "working" and demand that it be thrown into production for [insert business speak reasons]. Tech debt isn't always a decision made by the subject matter experts.
wool_gather 7y ago
I thought that was exactly the kind mentioned first: > We realized we could build something cheap that we didn’t mind throwing away later—scaffolding—to unblock getting user feedback sooner. If not, can you say more about the difference? I'm interested.

jakozaur 7y ago

Tech debt is inevitable and is good as long as you keep the level of debt reasonable, so maintanance cost doesn’t sunk too much of your dev time. More good examples: 1. Technology progress: Long time ago JQuery was the best for UI library. Today you would use React or friends. 2. Company stage. As a early startup you usually prioritize for speed and validating hyphothesis. As you got a significant user base quality matters more. 3. Size of development team. With 5 or less developers having a monolite is good enough. With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster.

jackcosgrove 7y ago
> 3 I think it's almost part of most companies' lifecycles that they start with a monolith, and anticipate rebuilding it as microservices if they get traction.
purple_ducks 7y ago
> With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster. Microservices aren't magic. There still has to be a contract between the services. Microservices are best when they are something which need to be scaled independently of the rest of the system.

Shinchy 7y ago

> Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! We do say Congratulations! - we say well done on finishing the project you were working on. I do agree with the part on not putting too much worth on edge cases, however the biggest issue for me with Technical Debt is the increased time it often leads to in further development. So I wouldn't say it's something to completely ignore.

sorokod 7y ago

So we asked ourselves, “What’s the simplest thing that would make the editor useful to our coworkers?” To me, technical debt is associated with a sense of regret. The example in the quote above doesn't have that, perhaps that is what makes it the good kind.

wellpast 7y ago
Perhaps this isn't "Tech Debt" at all. Perhaps this is a long understood, well-known activity called Prototyping or Learning. Perhaps the concept of "Tech Debt" is just fuzzy thinking.
- sorokod 7y ago
  Yes, something like that. When a suboptimal solution serves a strategic purpose it is not TD.
  - deleted 7y ago
    [deleted]

wellpast 7y ago

I'm going to take a more controversial position here, and it bothers me that it is even controversial. The very concept of Tech Debt, though prevalent, is pernicious, because its a concept that is far, far, far too fuzzy and therefore can -- and is -- always applied as a convenient narrative to explain away mistakes, process deficiencies, bugs, etc rather than a true conceptual problem-solving tool that aids in optimizing the software development process. In short, "Tech Debt" is a euphemism for incompetence. We can see this play out in this post, which covers "3 kinds of good tech debt. 1) "Scaffolding" ... what the author describes here is good ol' fashion Prototyping, aka Learning. No invocation of a fuzzy concept like "Tech Debt" is needed here. You don't know something, so you go and learn what you need to learn. Learning takes many forms. In this case, it is product understanding -- and this author reaches for prototyping in particular and calls it Scaffolding. Why a new term? Why obfuscate, why fuzzify? Because that's what Tech Debt is good for: fuzzy thinking. If we move to more clarity we can be specific and we can take specific actions to optimize: here, maybe or maybe not prototyping isn't the most efficient way to learn what is needed: often, wireframes shown to customers will suffice. There are plenty of ways to skin this once the framing is clear. 2) "Hardcoding" Again, no fuzziness is needed here. Developers have a fetish for fully flexible and feature-rich subsystems and we tend to call anything else a pejorative like "hard-coding" but that's a psychological problem in us, not a technical or process problem. We already have a clear framework for talking about this and it's called feature Scoping. There are, again, plenty of ways to skin this cat, but the short of it is - if you can understand what features you are interested in with clarity then you can build a system whose flexibility is in accordance. This isn't a fuzzy "Tech Debt" thing. If you only need feature X now and going forward, then build that - and call it something pejorative like "hard coding" if you want: I call it being rational. But bringing in a fuzzy term like "Tech Debt" helps nothing here. Only confuses. 3) "Not Fixing Edge Cases" This one is the worst of all. By using a fuzzy term like "Tech Debt" we're able to completely alleviate our responsibility. And start down a path of extreme cost and pain. Here, he wants to avoid having to implement correctness because it would cost too much. The example is a good one: it reflects a pattern I've seen over and over again. And unfortunately I've seen the same choice this author makes -- and the terrible downstream cost it creates, as well. By avoiding implementing a correct solution (by purposefully shipping a race condition) he is not being clever, he is being irresponsible. If this sounds draconian, let me explain further. Perhaps he finds, as he mentions, that in production this is inconsequential. Okay, great. But first thing to point out is that most likely it will become an issue as the system grows and when are you going to notice that? Are you going to go build monitoring to make sure that this "effective correctness" holds over time? Of course not, that's more work. But even if you are happy with his choice here, there's a bigger issue. He has chosen to build a system with transactional needs on top of an eventually consistent/NoSQL solution. From my experience, it's rare that you have just one feature like his that needs transactional correctness and that is it. Tomorrow, next week, soon--he and his team are going to find out that they need another transactional capability and then they are going to be right back where they started: having to ask a question, do I slack off here, as well? Again -- we've created cost for ourselves by forcing us to ask, should I ship a bug in this case? One might say this is what "Tech Debt" lets you do! It lets kick the can down the road, save you some time now... But I do not buy it. I've seen this exact kind of choice made plenty of times and the can always comes back next week, next month and the tax you pay for not getting right is immense. "Tech Debt" here is simply letting us avoid responsibility, avoid having to understand the needs of our overall system. The cost of getting transactions right/correct is not even that high if you face it squarely and truly make sure you need NoSQL and in which cases. What's happening here is not clever process optimization but inexperience. And if not inexperience, laziness (not the good kind). The concept of "Tech Debt" is awful. And always ends up being a euphemistic excuse. I've never seen the idea of "Tech Debt" help the actual process and technical quality of things. I've only ever seen it give developers an excuse for inexperience, laziness, etc. I don't mean to denigrate here -- I mean to challenge and ask for us to be more intentional, clear, and frank in our work. "Tech Debut" is fuzzy thinking and fuzzy thinking isn't much good for anything other than excuses.

nerpderp82 7y ago

If you aren't spending tech debt, you don't have a sound monetary policy. Zero tech debt is not a healthy goal.

wellpast 7y ago
Unlike financial debt, which has a clear quantitative measure, Tech Debt is an incredibly fuzzy concept to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.
- Raidion 7y ago
  But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it. Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your systems will almost always have limitations, it's important to understand these and communicate them well. Tech debt should be managed so it doesn't tip over and cause issues. Really good devs and dev managers develop the eye to see when that's about to happen and make sure they convince product that you need to pay that down soon.
  - wellpast 7y ago
    > Is it worth implementing a cache layer in a system? This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my system need to handle 1M concurrent users? If so, support that. If not, don't support it. But we don't need the absurd concept of "Tech Debt" for effective analysis. We can be specific. We can be clear. Does my system need to support low latency in the face of 1M concurrent users? Yes or no. Now proceed. "Tech Debt" is such a ridiculous dodge to otherwise avoid real analysis, real work, real clarity.
    - aeorgnoieang 7y ago

enginaar 7y ago

I'm failing to see the point in calling a technical dept "good". As far as I can tell from the article, the author is measuring 2 possibilities of technical dept and choosing the one that incurs the least dept. I can see how good a decision this is but I don't see how this makes the dept good.

rockinghigh 7y ago
It’s tech debt, as in a liability that you will have to pay back on the future.
kevsim 7y ago
> I don't see how this makes the dept good Time to market, for one. If you get the feature out faster to your customer, eating some debt can be worthwhile. This article is merely providing a structured way to think about the debt you're taking on.
weego 7y ago
Technical debt is a luxury companies with an excess of resources have. Startups without an excess of resources do not have technical debt in that, if you have no more runway and shutter thr business all you have is a bunch of code that didn't justify its own existence. By definition it is a positive situation to be in. So code that you can propose may be technical dept that make your Series A is good debt.

theptip 7y ago

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves adding tech debt. However, if you're mindful about where you take on tech debt, and commit to tapering and then paying it down as your resources grow, then you're more likely to avoid the debt spiral where your development grinds to a halt, due to everything breaking all the time. One other point I'd make is that a common form of "tech debt" for early-stage startups is simply doing things that don't scale; it's often beneficial to make your domain models flexible so that you can support one-off manual interactions, for example if a new customer appears that requires it. Then automate that thing and constrain the domain actions once you have collected enough use-cases to know what makes sense to forbid.

WorldMaker 7y ago
I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy. (Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")
- 7y ago

_bxg1 7y ago

This is a good take.

cjfd 7y ago

@1: One could also have automated tests instead of scaffolding. @2: Sure, but this it not really technical debt. It is the wise policy of not immediately writing code for the most general case. If one writes several instances of this it would lead to code duplication that would need to be refactored immediately. @3: Careful with this one. The thing is that the thing you call an edge case might have the more proper name of 'bug'. If you deliberately leave in bugs at the time of writing the code it can lead to very difficult to estimate 'stabilization time' at the point where the code is supposed to go into production but is not quite reliable enough. It becomes somewhat difficult to explain if that 'stabilization time' turns out to be months or even as much as a year.

HelloNurse 7y ago

The defining characteristic of technical debt is attempting to avoid paying it, taking shortcuts that create "interest" in the form of increased effort and cost; it's always bad, but depending on timing and costs it can range from a "correct" minimum cost choice (e.g. badly tested truly throwaway code) to a stupid mistake to an existential threat. Technical debt is a close relative of externalization (I save time, you waste time) and of mistakes that result from incompetence rather than from haste and shortsightedness. All three sections of the article, instead, describe healthy planned evolution from a decent provisional product to a better one, with solutions that might be rough but not necessarily bad. In other words, a clickbait title for sound (but maybe unrealistically mature) examples of properly pragmatic project and product planning.

mlwhiz 7y ago

Sometimes going in a Hardcode way is much better than going around in circles to get the perfect code. Saves time and is more intuitive.

ChrisCinelli 7y ago

> Good Tech Debt Is Intentional When it comes to accelerate development in my opinion this is most (80/20) of it.

davnicwil 7y ago

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that, so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save time and get something shipped, knowing that it will cost you more time than you're saving now to fix it later. But by shipping now, you ensure there is a later, with a product that's out there and being used, a bigger team and therefore adequate time and then some to fix the debt and keep improving the product. Everyone wins. That's the theory anyway. I think mostly where it goes awry in the wild is people forgetting the paying it off part. Part of this deal is you have to pay back your lender - they have to win too. It's just easily forgotten because you're the lender, so the incentives get a bit conflicted, and you'll keep giving yourself more time. But if the lender ultimitely doesn't get paid back and loses, you lose, and it's a bad debt.

matchagaucho 7y ago
Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."
- chris_wot 7y ago
  Michael Feathers said that he doesn’t use the term when working for banks as they don’t see it as a negative term...
tempestn 7y ago
> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.
- eikenberry 7y ago
  What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?

momokoko 7y ago

I've always believed that "debt" is not a great term for this. Because it does not really apply to financial debt. Financial debt is often repaid simply by bringing in more revenue because of the benefits gained from bringing on the initial debt. The only risk involved in the debt is that there will not be enough money to pay it back later. It is a very predictable and obvious issue. Technical debt is closer to educated gambling. You are taking a risk that the shortcuts you are taking will not pop up and hurt your company before you fix them. You are essentially saying, "We know this is a problem, but we are estimating that it won't hurt us for the foreseeable future". The better analogy to technical debt is investing. You are getting a certain percentage increase in productivity(a dividend or other capital gain) for the (hopefully low risk) gamble that your investment will not have a problem and wipe it out or simply cause significant losses. Developers typically do not like this because when the inevitable few cases of these "investments" turn bad, they tend to be the ones that take on the majority of the blame.

k__ 7y ago
To me they even sound the same after you explained them. Not being able to pay back money sounds like the same as not being able to fix bugs.

dredmorbius 7y ago

JS-mandatory text-only blog posts are bad tech debt. https://outline.com/fH9GzD https://outline.com/fH9GzD

deleted 7y ago

[deleted]

onemoresoop 7y ago

I'm not sure how this classifies as tech debt, but in my experience the worst type of tech debt is found in parts of a system that is relied upon and whose business logic has become unmaintainable, is too complex/poorly understood and is not possible to throw away as too many things depend on it. Also usually whose initial creator is long gone, the documentation is conflicting with the code implementation. This kind of debt causes eternal confusion and constantly lowers the productivity of the team. In cases like these, workarounds are created and more tech debt accrues on top of it that is even harder to reason about. Nobody sane can fix a mess like this and the only hope is death of the system or complete overhaul.

munk-a 7y ago

Tech Debt is never good, but it can be acceptable in exchange for a greater gain. So, just like this article's opening: > Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! Except it is universally reviled, no one wants debt - they just accept debt in reasonable quantities as a way to efficiently get things done. I think, in particular, the success of not-quite-agile-but-similar business practices has confirmed this, plan carefully and evaluate business needs, then get it done in a way that's fast and leaves you relatively free of debt - don't plan for everything. So don't get stuck in analysis paralysis trying to build the perfect things - and don't just code with no thought of the future... it's a difficult road to follow.

somesortofsystm 7y ago

No, and no, and no. Just fix it. Repeat until completion.

vinay_ys 7y ago

Nicely done. Good to see an engineering blog acknowledging tech debt openly. I'm with you all the way until the last paragraph which short-changed the conversation a bit. Quoting a few lines to respond below: >> Build things to be easy to throw away and replace; it’ll make your code more modular. One valid strategy to manage debt is to declare bankruptcy or amnesty on debt – that is throw away the code (because this code is no longer needed). In domains where this possible, definitely use it. But in most real-world touching software domains this is not likely possible. >> Good tech debt has clear, well-known limitations. Document these in code comments, READMEs, FAQs, and conversations with the people who’d care. Doing tech debt accounting in a more formal manner is required to intentionally take debt. In the locking example, it is a design debt (not just a code debt). If the debt isn't document well and then it can become a ticking time bomb to be tripped by a clueless developer later.

jboy55 7y ago

Tech Debt, to me, grows with every line of code you write that didn't replace a line of code. Consider how many projects start with the idea, 'I'll rewrite this and get rid of the tech debt'. First, If the original code isn't deleted, you've added to the tech debt. Now every new engineer will need to learn two chunks of code, and every existing engineer will need to support both. Second, unless you've had a major epiphany between the old code and the new code, you're more likely to run into the trap of the first example. Major epiphany's could be, 'wow, we really didn't need all of that extra stuff', or, 'we've duplicated so much code, we should re-organize this all'. I've been at plenty of companies where you have to understand that the Perl code is really old and these components use that, the Mason rewrite was 80% done and is over there, the Next Gen code was in Ruby these components do that. But now, we're embarking on a new Node/React project to replace all of it, finally going to get rid of the tech debt! (Said with no sarcasm)

theturtletalks 7y ago
If tech debt is inevitable, what’s the solution? Good internal documentation and rewrites every few years?
- rickbad68 7y ago
  a practice of constant refactoring..
qes 7y ago
And I would say that's an example of when it can be good to purposefully take on technical debt. In my experience there have been plenty of significant refactorings that simply would not have been done if we didn't allow ourselves to get into this state where there is simultaneously an old and a new way of doing something. Especially if it's an area that sees frequent addition - it's not helpful to have people constantly adding code in the old way while off to the side people are trying to create a new way and completely finish switching everything over to it before integrating. Managing risk and balancing other active tasks in the pipeline also push towards integrating smaller pieces over time while multiple ways of doing the same thing exist. But you need to have organizational continuity, which can be rare when everyone is trying to hop jobs for better salary every couple of years.

opportune 7y ago

I think that "Good Tech Debt Is Intentional" is the key point. If you are able to recognize something as technical debt as it is created, you can also more effectively plan for paying it down later, and note what you think the solution would be at a high level. The real issue with tech debt is not that it exists, but that people wait too long to pay it down, and then end up taking more dependencies/making more technically bad decisions to deal with the tech debt which just makes it even harder to fix.

jdance 7y ago

I take a chance and say it right out: Fix some kind of image library functionality! As a customer who's also used Wordpress (everyone?) its just madness that I have to keep originals on disk somewhere to post it onto another page. I can hardly figure out how to download the full size original to be able to upload it again. I ask you humbly, please, you have the power to improve my life! If you want me to stay on topic -- this is the worst wasted time debt Squarespace has to me as a customer :) code wise the product is really solid so their philosophy is obviously good!

deleted 7y ago
[deleted]

tams 7y ago

Technical debt is a wonderful ally when building prototypes. Imagine you are building a prototype and you are clever enough to only focus on validating an idea. Having this focus you ignore all best practices and maintainability issues you might tend to out of habit. What you are likely to end up with is a functioning application that resists change beyond its original goals. And this is good. It lets you declare technical bankruptcy early enough to avoid painful rewrites on a software that was not meant to exist for long anyways.

spc476 7y ago
As long as both sides (developer, management) are aware of this (he says, as his "proof-of-concept" was installed into production directly by his manager with no warning).

anonygler 7y ago

> if now >= NEW_CONTENT_DATE No canary? Tsk tsk.

louwrentius 7y ago

This was an amazing article.

another-dave 7y ago

"Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations!" There's an implicit assumption there that your friend can afford the purchase. If banks did no credit checks & your friends were impulsive & broke you might try to talk sense into them instead. Maybe we need to store PM's technical debt for 10 years and perform a credit check when they say "I don't care, just ship it & we'll clean it up later"!

rkagerer 7y ago

Great article. But the only reason their approach to the "11 item" edge case works is that they manage their own data. So they can monitor and might potentially cull manually if it became necessary (eg. What if the race condition caused more than 11 or a future codechange elsewhere stumbles on it). In a non-cloud product where the cost is higher for a vendor to come verify and fix data, this wouldn't fly.

jkoudys 7y ago

Love love love this article. I'm so tired of hearing lazy, unskilled, disorganized, mismanaged, etc. companies handwave the shit they write as simply being "tech debt". Sticking 50ms waits throughout your code, because you're not good enough to figure out how to actually trigger your action from an event or await something completing isn't "tech debt". Maybe hiring people not good enough to figure it out could be considered that from a higher level.. If we are going to allow the tech debt metaphor to continue, too much of the debt I see is the equivalent of a pay-day loan.