26 ms·

Technical debt as a lack of understanding

• thefourthchime 6y ago
  I'm disturbed by the ending justification for rewriting or refactoring code. I've seen countless failed attempts. Either you make a clean break and create something small and simple enough to solve 80% of the old products problems and grow from there, while eventually letting the old product die on the vine. The other option is to take out the cancerous parts of the older system, carefully making sure you didn't break anything.
  • zinekeller 6y ago
    This is correct. Ossification of the application means greater technical debt but throwing it all away is bad unless either it is an internal application and you can spend time identifying related applications that operates beyond your documented APIs of the application or met the ire of your external customers (equals PR disaster). The correct handling of this on a new project is to insist on fully documented public APIs so that you can rewrite that without too much worrying. On existing ones, rewrite in parts with extensive internal testing (and if possible testing with your customers, but please do not use the modern Microsoft way of almost no internal testing) and full rollback plan in case it went disastrously wrong. Or just as this comment said, just create a new product and have a workable migration plan.
  • Shog9 6y ago
    The choice is an illusion. Both strategies require understanding the requirements implicit in the current system. The first just assumes many of them are low-priority; this is frequently a dodgy assumption. So, regardless of which path you take, most of your journey will be extracting requirements, writing tests, discussing priority with stakeholders. At the point where you're finally writing new code vs modifying existing, most of the journey is already behind you.
  • lbriner 6y ago
    I would say they are the worst two options. The rewrite is mythical because not only does it invariably take much longer than it seems that it should, how are you going to carry on working on the existing system while spending 2 years rewriting? Depending on your codebase, removing a specific part of it is invariably extremely brittle and the people who understood the original app might not be around any more. The third, and imho best option, is to deploy something new alongside the existing application. For example, the existing email system is massively over complicated so we created a new email microservice system which didn't only permit a rewrite, but was a small achievable system and could bring with it many other benefits over the code in the monolith, it was then relatively easy to both test and redirect the original calls to the new service. You can also do this with applications. We run two alongside each other behind a proxy to hide the movement between the apps. We only need to migrate one page/area at a time, test it and then automatically redirect that page to the new system. This approach is much more practical and also gives the benefit that if you are doing a major redesign, you simply migrate that page at the same time to the new app and you test everything at the same time. Leave the old stuff alone and eventually delete it all. Lovely.
    • hyperpape 6y ago
      If you have a reasonably sized/established code base, this may not work. My company is trying to deploy new things as microservices, but unless we actively make major efforts to pull things out of the existing monolith, it will grow faster than the sum total of the microservices.
    • spfzero 6y ago
      You've described what I would call a "rewrite", just one that was thoughtfully planned out. Another benefit is that you have the existing, running system, to use as test validation. If the new black box works exactly like the old black box, you're good. Of course you need to do a few things like go through an end-of-year with both systems to make sure you found any lingering differences.
  • spaetzleesser 6y ago
    “The other option is to take out the cancerous parts of the older system, carefully making sure you didn't break anything.” To me that’s the preferred approach. You can rewrite the really bad sections and you can also restructure the code so it’s possible to rewrite components in other languages/stacks later. But it’s hard to communicate this to other devs and also up the management chain. Devs don’t like it because it’s not “cool” and also requires understanding of the current system and management doesn’t like it because it adds overhead to development so new features get rolled out a little slower.
• jspaetzel 6y ago
  This is such a solid take. I'd extend it to say that sometimes technical debt appears to be so when really you don't have a complete understanding of the problem. It may help to spend more time learning the problem domain. Maybe refactoring is part of how you learn, however it's arguably the most dangerous way since you risk breaking things without understanding.
• peterlk 6y ago
  This is well put. I want to expand on one point that seems to be lurking beneath the author's remarks. Technical debt does not necessarily come from technical people. If you're in a startup, there is almost no way that you can end up with a small amount of tech debt because the target that you're aiming at will change. And if you over-optimize for code cleanliness too early, you'll end up shipping code way too slowly. Slow, deliberate code writing is better suited to large, established companies than small, scrappy startups. You cannot escape tech debt; it can only be managed.
  • dheera 6y ago
    In my experience technical debt almost always comes from management's misconception that: (a) A product that works now will always continue to work, even after you accumulate 10X the number of users. (b) Adding new features only involves adding code, not rewriting stuff that already works. (c) For a product A, delivering milestone A1 by deadline A1 is independent of delivering A2 by deadline A2. In reality the existence of A2 affects the timeline and architecture decisions of A1. All of these are rampant massive fallacies in technical management.
    • mlyle 6y ago
      Most startups can expect to either A) have a lower cost of capital in the future, or B) to fail. This means opportunity cost is ridiculous, and expedience often can be worth a whole lot of future wasted resources and decreased velocity. Survive to tomorrow, where you have more resources and can pivot to doing things in a cleaner way. So it's not completely stupid to pretend A & B are true. You can pick up velocity now, in exchange for future problems. And as long as the interest payments aren't too high it's well worth it.
      • dheera 6y ago
        Sure, it's a valid way to think for startups, but startups should gauge and plan for the amount of technical debt. It's management being ignorant of technical debt where things become problematic.
    • 6y ago
• dec0dedab0de 6y ago
  The title made me want to reply that if you didn't purposely decide to take a shortcut then it's not really technical debt. But after reading the article I 100% agree, and I'm going to send it around for our team (and manager) to read.
  • nullsense 6y ago
    Not sure if it's the technical term for it, but if you didn't decide to do it on purpose I believe it's called "cruft". People kind of use them interchangeably sometimes though.
• Datenstrom 6y ago
  > When we notified management they replied, “We’re in a build the plane while flying situation, how can we get this out now without doing a big rewrite?” Even worse I tried to catch this before it happened at one company and was stopped. I was transferring to a new project and was the only person who had any experience with a system like they were building at all and was not consulted at all for the initial design. They had made a fatal design mistake that I knew would sink the project and I raised my concerns. Turns out a "technical" manager had made the decision and he wouldn't budge on it for anything. All of management then attempted repeatedly to gaslight the entire team claiming that they had "decades" of experience with the tech and that it was the correct decision despite being given solid references about the problem from many reliable sources outside the team, and continued to say things that directly contradicted the sources. The project hadn't even started yet so the entire situation could have been avoided. Nearly every competent team member left within a few months. Before leaving I witnessed new hires do everything from pushing AWS creds to git to pushing over a GB of docker `.tar` files to a repo... it was bad. Seems just a few middle managers can drown a project/company in technical debt pretty quickly. Edit: "every competent team member" to "nearly every" not sure why some are still there.
  • zinekeller 6y ago
    Wow, that "manager" is really bad, since that "manager" does not accept any suggestions (equals having a big ego), and it seems that there was no backwards compatibilty to be worried about. Why do I feel that "manager" is trying to micromanage everything?
    • Datenstrom 6y ago
      Otherwise I would definitely not say they tried to micromanage everything. Maybe they thought they had a good understanding of that particular problem I am not sure, but the solution had already been pitched to the customer before I transferred to that project. It likely had more to do with politics than his ego. That it was never going to work would be obvious to anyone who had worked in that space though.
      • 6y ago
• underdeserver 6y ago
  To me tech debt is the result of callous introduction of invariants. An inexperienced engineer keys your users table by their email. Suddenly a user changes their email address, and now you either refactor to use an autogenerated user ID (as you should have in the first place), or you have a huge brittle process for migrating a user between emails, or your entire codebase starts getting littered with statements looking for previous email addresses and copying data on the fly. The mistake was that email=user identity is not a true invariant.
  • C1sc0cat 6y ago
    Who doesn't have an auto increment Id field on every table? Ok I know its not a 100% perfect solution for a user id. The other gotcha is using ss on ni numbers as identifiers
    • taffer 6y ago
      What is "ss on ni"?
      • marcosdumay 6y ago
        I read that as "social security number or national identity", the "on" being a typo.
      • Jtsummers 6y ago
        Probably "session".
    • brlewis 6y ago
      > Who doesn't have an auto increment Id field on every table? In large organizations with a lot of teams, natural primary keys make interoperability easier across databases, as opposed to a forest of artificial keys that are all different. SQL experts who advocate natural keys point to ON UPDATE CASCADE as the solution to natural keys that occasionally change. So the absence of an auto increment Id field might be a dumb error, or might be super smart, or might be both. Both means you're a SQL expert but haven't made sure everybody else working on the project always will be.
• dm03514 6y ago
  Shameless plug, I recently tried to characterize technical debt in terms of time pressures and system understanding, i think it's related to this parent post: https://medium.com/dm03514-tech-blog/technical-debt-poor-system-understanding-while-time-constrained-66385d110498 https://medium.com/dm03514-tech-blog/technical-debt-poor-sys... I believe a lot of tech debt is choosing locally optimal solutions, and that leads to organizations never reorganizing the code to reflect their understanding.
• Stierlitz 6y ago
  “I can’t tell you how many new product initiative meetings I’ve been in where no one remembers the meeting about the exact same thing from two quarters ago. It’s like Groundhog’s Day, but you’re having the same meetings over and over.” Haaar!
• dfltr 6y ago
  I've had to explain this to non-technical stakeholders many, many times over the years, and I always use the restaurant metaphor: If you run a commercial kitchen and you only ever cook food, because selling cooked food is your business -- if you never clean the dishes, never scrape the grill, never organize the freezer -- the health inspector will shut your shit down pretty quickly. Software, on the other hand, doesn't have health inspectors. It has kitchen staff who become more alarmed over time at the state of the kitchen they're working in every day, and if nothing is done about it, there will come a point where the kitchen starts failing to produce edible meals. Generally, you can either convince decision makers that cleaning the kitchen is more profitable in the long run or you can dust off your resume and get out before it burns down.
  • elric 6y ago
    > or you can dust off your resume and get out before it burns down Last time I left a job, this was a big part of it. The company simply refused to learn from their mistakes. Now I find myself in a similar boat again. The only thing that seems to matter is the day's emergency, and everything else is put off indefinitely. This, obviously, leads to more emergencies in the long run. And yet for some reason the company seems to be coping and is growing rapidly. Perhaps it is time to dust off the ole CV again, or perhaps this is a transient thing. Time will tell?
    • chrisweekly 6y ago
      IME (22+ year career so far) there's a balance to be struck. If you wait to ship till you're happy w the code, you probably waited too long. Successful businesses are often built on surprisingly shoddy software, and time to market matters. OTOH, only ever running in naive startup mode -- "ship it yesterday, add features nownownow, any means necessary, shortcuts be praised" -- is a recipe for disaster. Given your strong feelings on the matter, maybe you could find a way to help surface the costs and help your org to start fixing them. Because some amount of it is inevitable, and things within a given company only get better when someone cares enough to do something about it. If it works, you're a hero and things improve. If not, you can still jump ship, but with a much better narrative: not "I got tired of the intolerable levels of tech debt", but "I did (X) in an effort to address [same], but ultimately couldn't overcome the institutionalized patterns that led to it, so I'm looking to work for a company that cares about software quality".
• 02020202 6y ago
  tl;dr but when it comes to TD the thing is - it does not matter. programmers care because they see behind the curtain, but business does not. if it makes money, it does not matter how fragile it is. business is looking at things like black box that has input and output and that is ALL that matters. on the other hand, programmes have the inverse outlook. they do not care much about what goes in or out but what and how is happening inside. and in the grand scheme of things, all that matters is if it makes money. this is one thing that many new programmers struggle with because yagni/kiss is impossible for many to implement even if they really want to because we as a human species have hardcoded to take the path of least resistance and in code that means avoiding repeating yourself or writing "ugly" code and things like that. only after decades of being in this business will one learn how to let go. but it cannot be forced or learnt on the spot. it has to be experienced. yagni, bitches.
• aazaa 6y ago
  > If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer. The author doesn't take the next logical step: what factors prevent the reorganization of a program? One factor that comes to mind: lack of automated tests. Those working on the program are scared to change anything for fear of breaking something.
  • elric 6y ago
    > One factor that comes to mind: lack of automated tests These tests have to be at the right level. Unit tests are the easiest to write, but unit tests can be pretty brittle. Reorganizing the codebase can result in many unit tests breaking (or being made redundant), which might lead to stagnation from fear of breaking tests (and the extra work of fixing them). System tests are much harder to write, but are invaluable during a major refactoring. You want to be sure that you're not changing the behaviour of the system while changing its structure. The V-model is (IMO) an underappreciated tool in the development lifecycle.
  • laksdjfkasljdf 6y ago
    Writing tests without fixing the lack of understanding first is even worse. Now the next cycle will have to understand not only the code, but why some test is validating some unused endpoint with data you never thought possible
    • ornornor 6y ago
      That’s where comments come in. I tend to do a brain dump around the code I wrote in comments: why does this code exists and in particular why is it doing it in this horrible, convoluted, suboptimal way. I also wrote small functions and pick my variable names carefully. My colleagues think I’m an idiot writing too many comments and being too careful. We can’t ship any feature in less than 3–4 weeks, most of the codebase is an inscrutable mess, and we introduce regressions all the time (unit tests are for losers)
• tonystubblebine 6y ago
  Unpopular opinion, probably here, but definitely among people I've shared this with before: The phrase technical debt is a red flag itself and probably should never be used. Most people seem to get that the issue of technical debt is really a business issue about tradeoffs. So, if the person who is concerned about technical debt is senior enough they will have some ability to see the business tradeoff and thus can completely avoid the phrase. They'd say instead something like "I was thinking that if we changed X we would get value Y." A person who uses the phrase Technical Debt is signaling that they aren't capable of saying something that direct. That's one issue. And then the other issue is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. It's a junior engineer who says, "this is a huge mess and I need a full stop of my contributions to the business so that I can focus on untangling it." But the problem with junior engineers doing refactoring/rewriting is that they end up creating a different mess of code and bugs. Am I right 100% of the time about this? No. But I'd love to raise for engineers here that although the phrase technical debt caries a lot of emotional weight, it also brings a lot of baggage from all the times management has heard the phrase from someone that didn't understand the bigger picture. With a little bit of work you could understand the business implications and then end up completely avoiding the use of the phrase.
  • dvt 6y ago
    > And then the other is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. I'm quite senior, and I don't think this is true. Refactoring "as you go" is a no-go for a few reasons: (1) Roadmap (read: business) goals need to be reached and unless technical debt is a part of roadmap discussions -- it's usually not, because business people don't "get" code -- then it will naturally be of lower priority. (2) On a technical level, technical debt changes/re-arch should not live in feature branches. On a deeper technical level, technical debt pull requests and reviews will also usually incur a higher level of cognitive load (and thus will take longer to merge). Conflating technical debt and new features is a Bad Idea™. (3) This final point is a bit "20-20 hindsight," but with proper roadmapping and architecting (and unless you're building an MVP or proof of concept at your two-person startup), technical debt should basically not exist. Technical leaders should always push for high-quality code (even if product timelines are stretched) and technical debt is, generally speaking, a byproduct of bad technical leadership.
• drewcoo 6y ago
  > I like this definition That's a quote from Ward Cunningham, who coined the term "technical debt," so I'm glad the author enjoyed Ward's version.
• mkl95 6y ago
  There are many dimensions to technical debt, but one of the biggest is the sociopolitical one: developers hate fixing each other's bad code, but the people who wrote it are often in a position where they can transfer the ownership of this code to someone else, either by being their managers or by quitting their job.
  • Jtsummers 6y ago
    I actually liked doing that. I wouldn't want it to be my only job, but management usually wouldn't even let me do it for a few hours a week. It's like a puzzle, it was very satisfying to take something functional but sloppy and create something functional and maintainable (often reducing code size significantly, reducing memory footprint by identifying redundant variables, speeding things up by identifying redundant code paths, etc.).
    • marktangotango 6y ago
      I agree it can be very meditative. I actually seek these types of jobs nowadays.
• jennyyang 6y ago
  Technical debt is best understood exactly as the term suggests, like a loan. When you keep incurring more and more loans, you have to pay interest. At some point, the interest payments will get so high that it makes sense to restructure the debt somehow. Loans and debt are good because it helps you grow when you need it, as long as the interest payments make sense. The same goes with code. When you let bad code enter a project, you do it with the understanding that you will need to pay some interest payments on that for the duration that the code is in the repo. Some technical debt is a good trade off between agility and code quality. Saying you should never have technical debt is the mark of an immature engineer. But if you keep piling in bad code into a repo, you will have to keep paying interest payments on more and more bad code. At some point, there is so much bad code that the interest payments are too high even for a senior manager to deny. I disagree that you should refactoring code "so that the entire team can understand the code". Teams turnover much more frequently than a code base should. If you need to keep rewriting every 3-5 years, your senior engineers are probably very inexperienced and architected the code poorly.
  • yourabstraction 6y ago
    This is exactly how I look at technical debt, yet it seems so many people miss the appropriate financial metaphor, which seems obvious given debt is in the name. It seems popular to conflate technical debt with bad engineering, but appropriately pushing work off to the future is actually very thoughtful engineering. Technical debt is a tool that can be applied (just like financial debt) to work towards an end goal when you otherwise don't have the means to pay the price upfront. Getting a startup off the ground requires an excellent understanding of how much technical debt you can incur and realistic estimates about your ability to pay it off as your team grows.
    • crdrost 6y ago
      This blog post we're all commenting on is great precisely because it links Ward Cunningham's talk. His understanding is precisely this financial metaphor. I have considered giving a talk, “When Technical Debt was a Good Thing”. Like you say, it gets mis-equated with bad engineering but originally the point was that technical debt was a good thing, like, let's have some technical debt! This is gonna be great! If you’re looking at 1980s attitudes on software development, there was a strong focus on getting the engineering right, we're gonna be like generals and we're gonna have a vague direction of success and then our lieutenants will reify that into a concrete plan of success and then the privates will go off into the trenches to, here the metaphor finally breaks, build the application: and then we'll evaluate their performance on fidelity to the design that the lieutenants gave and we'll evaluate the lieutenants on how well that design matches the goals the generals set out to do. Very hierarchical, design-first. And the point of this metaphor was, “No, stop. Stop with all the BS. Get those privates building something right now. Doesn’t matter if it’s not the thing the lieutenant would have designed. Let’s intentionally build the wrong thing.” And it’s like, shock and horror, why would you ever want to do that? Then comes the metaphor. “It’s like spending money you don’t have, people act like it’s impossible or perhaps like it’s immoral—it’s neither. Credit systems exist. Debt exists. We’re just lifting that notion to the technical sphere.” Why would you want to do it? Same reason you take on any other debt: you think that you can outrun the interest. I take out a car loan because I think that the car will help me earn enough to cover the loan repayment amounts and save me time and/or money. In this case, because we don’t have the final design we’ll only conform 90% to what we’re supposed to be producing, say. That 10% loss is the interest. We pay it because we think we can cover it later. Very much, Agile is an approach to creating technical debt. The opponent of both is the same, a "waterfall" style where you know exactly what needs to be built before you build it.
• deleted 6y ago
  [deleted]
• gfairbanks 6y ago
  Related treatment: ABSTRACT: The term technical debt was coined by Ward Cunningham in 1992. In recent years, people have broadened the definition to include ideas not present in the original formulation, including lack of skill, expedient hacking, and obliviousness to software architecture. By lumping these together, it’s harder to choose the right repair. This article proposes that we use the term ur-technical debt to refer to the original idea, which was: When I build systems iteratively, my understanding of the problem and solution grow gradually, and inevitably my current thoughts do not match code I wrote earlier, so I must expend effort to fix that code, much like paying interest on a debt. https://ieeexplore.ieee.org/document/9121630 https://ieeexplore.ieee.org/document/9121630. Ur Technical Debt
• ChuckMcM 6y ago
  I like this metaphor as well. It happens in code and it happens in systems. And often we call technical debt "legacy" because changing it would require too much re-organization. I used to use the metaphor of coral beds for systems design. All the new development you're doing on a system is the vibrant ecosystem in the coral, and then you ship the system, and now when parts of that ecosystem becomes irrelevant you are still stuck with it for "legacy reasons" and now its bones are calcified into the reef underneath the system. Think of it like the VGA register layout for video cards on x86 PCs. Fully mapped frame buffers make so much more sense for a 64 bit system but so many things are constrained by the legacy of code that assumes the VGA register set that it isn't worth changing. As I've become more experienced, I have come to better appreciate the cost of technical debt which has the side effect of slowing me down because I find I don't want to commit to code until I fully understand the system, even if it currently passes all tests.
• lacker 6y ago
  I think the term "technical debt" is a really good analogy. Regular financial debt isn't something to be avoided at all costs. Often, it's the right move to take on some debt in order to quickly achieve an important goal. Taking out a loan for a house or a college education can be a good investment that pays off. But at the same time, if you completely ignore your financial debt, you're going to find yourself overwhelmed by your debt payments. The key is to be aware of your technical debt, and be aware that you're making a tradeoff, and that the right answer often falls between the two extremes.
• b0rsuk 6y ago
  What if technical debt happens on purpose ? Clever programmers incur technical debt, then leave company. Debt incurred becomes another bullet point on their resume, and they eventually become Senior Developers. Their debt is paid by someone else. Maintaining an app affected by technical debt is a thankless job and you don't get much bragging rights afterwards. But the programmer who incurred debt can look good in the eyes of management, after all he worked SO FAST and you're the bitter, toxic person who complains.
  • keutoi 6y ago
    That would split the profession into maintainers and initial writers pretty quickly. Maintainers will become scarce and hence quite valuable.
    • bgorman 6y ago
      Not when you can hire an overseas "maintainer" for 1/4th the cost of the average dallas developer
    • b0rsuk 6y ago
      I think the split has already happened, but I'm not convinced maintainers are perceived as valuable.
      • BenoitP 6y ago
        > I'm not convinced maintainers are perceived as valuable. I'm pretty sure an accountant classifies technical debt control as not being valuable. "A cost center is a department or function within an organization that does not directly add to profit but still costs the organization money to operate." Want to stay compliant with privacy laws / norms / standards / file formats in your useful custom software? Gotta pay some technical debt dealing with that new complexity; just so that you can continue to operate at the same provided value. Necessary, but not valuable. rant And then you go and try to get a raise. /rant ---- My cynical side tells me that it is a sound personal strategy to declare that old languages like Java are outdated, and that the only way forward is with the newer shinier languages. This way you would only get greenfield projects. I should do that, even though I love Java.
• magicalhippo 6y ago
  Programming is all about trade-offs. The trade-offs of an implementation can lead to technical assets as well as technical debt. It's just that most of the time the technical profit isn't noticed as much as the technical debt. And as with regular debt, the "interest rate" can also vary wildly. Some debt just sits there, doesn't change much. The code is a mess, makes fixing bugs harder than it should be, but it doesn't impact new work much. Other debt is like a credit card, where you continue to pay a price every day, and it can severely affect your ability to implement new things. Then again the same is true with technical assets. Make good choices and you can reap the benefits for a long time. Implementing new features can become 5 minute jobs rather than taking days. Sometimes you're aware that you're about to swipe that technical credit card. Other times it can be an inadvertent decision, you went right instead of left while thinking of something else. That's the tricky ones.
• k__ 6y ago
  In my experience, the problem is two-fold. 1. There is a contract that forces people to deliver something on time. 2. The people who should deliver think they know how, but they don't and they won't take the steps to learn it because they don't know how to learn it or because of 1.
• didip 6y ago
  An even easier solution is to simply work for a tech company that values you as an asset instead of cost-center. In such companies refactoring discussion is normal and protected (within reasons). Where as in a cost-center company, refactoring often felt like moving Mount Fuji with a spoon alone.
• sergioisidoro 6y ago
  I've been thinking about this topic a lot, and I ended up putting some things into words [1]. I think what we are lacking is proper taxonomy for code issues. Nowadays we fall too much into classifying everything as "tech debt". For example: I especially love the metaphor of technical debt. But we should consider the other aspects of debt - You only take on debt deliberately and so that you can invest the time / money on something that will yield a return on investment. Calling bad code "technical debt" breaks the metaphor for me. We probably should stop calling bad code "technical debt" [1] - https://isidoro.io/writing/tech-debt-broken-windows/ https://isidoro.io/writing/tech-debt-broken-windows/
  • spfzero 6y ago
    Interestingly, one place I worked we had a 20% set-aside for technical debt. This resulted in endless arguments with product owners who wanted to categorize bug fixes as technical debt. Sadly, some of the less experienced engineers would take this side in the argument, as well.
• silentsea90 6y ago
  TechDebt is CareerDebt. More often than not, techdebt is added by somebody else (who got rewarded for their product impact) but is your careerdebt since organizations seldom reward clearing techdebt, even at the best of tech companies in SV. The only time organizations reward clearing techdebt is when the sh*tshow gets so bad it either has visible velocity/infra/product impact that just can't be resolved without a dedicated 1 year effort to clear the crap. I have seen smart engineers pile on to the techdebt as there is no publicity or heroic story around taking a bit of time to clean up the mess on a regular basis. Sadly it is a game of visibility so engineers do what the management chain wants to see and knows is a problem
• xrd 6y ago
  It's so great that this article is about Ward Cunningham who coined the term technical debt. And, the "bad example" used as a metaphor for technical debt is the "out of date" Wiki. Ward Cunningham also invented Wikis.
• solidist 6y ago
  A metaphor I like on technical debt is a reoccuring monthly power utility bill that is mailed to the team. Everyone pays bills, so there is no abstratcion. Teams prefer to keep it constant and portitonal to the utility of the structure standing and building. Every so often it goes up and phoning it "in" to the company to pick up discounts. If the bill is unchecked, eventually it will sap away all of the monthly expentiure. When the rate is unmanageable, the team members look at each other in disbelief.
  • nullsense 6y ago
    This is why I refer to it as Technical Tax. Your technical tax bracket is proportional to the amount of cruft and bitrot in the system. A technical tax bracket of 100% means every last bit of development effort is expended on simply maintaining the status quo. So, efforts to lower technical tax bracket can come from refactors, and cleanups, but also from introducing new technologies that diminish current limitations unlocking new capabilities.
• jdlyga 6y ago
  "Our oven is from the 1950s, and only one of our 5 cooks knows how to operate it, but it's ok because she's usually there everyday." "Our knives are downstairs locked in a storage cabinet that our manager upstairs has the keys to. So we usually chop everything with scissors because we need to get food ready fast." "What do you mean you can't make this recipe that's 48 pages long? The chef who used to work here made it, he was a genius. Aren't you a chef too?"
• luord 6y ago
  My current approach to technical debt is not mentioning it, and instead attempting to make small refactors and/or writing tests for uncovered sections of the code as I go along. Also adopting an attitude of letting it go if my attempts or suggestions are stopped. That latter thing is more difficult as it means efforts to help go to waste sometimes so my first instinct is to insist, but ultimately I tell myself that it's the clients' code and their decision, not mine. Besides, cleaning up code, sometimes by trying different ways to clean it, is always a teachable moment. Fortunately, my current clients have been far more receptive and open to improvements than some other people/companies I've worked with before.
• galaxyLogic 6y ago
  "Technical Debt" is a problem whatever we call it. It is a worse problem than real financial debt because financial debt is easy to measure in dollars whereas technical debt is not. There is no reasonable way for measuring technical debt I've seen. The amount of technical debt is difficult if not impossible to quantify yet it is intuitively clear it is an issue. You add code to your code-base making it do more and at the same time making it less optimal in how the code is organized. At the same time you know you perhaps should spend time and effort to re-organize it, but how much? How often. Maybe you have a rule of thumb but who's to say that rule is "correct". Trying to lessen the amount of technical debt happens by what is called "refactoring". While it is clear that at some point we better do some of that, the unanswered question, and the reason why "technical debt" is a problem, is how much and how often should we refactor. I haven't seen any clear guidelines for that. Are there?
• phendrenad2 6y ago
  One big danger of "technical debt" is it can appear impossibly shiny. People want to work on it, despite there being high-priority features that need to be implemented, for instance. This is because technical debt is a code problem, while adding features is a business problem. Programmers like to stay in code-land.
  • ornornor 6y ago
    And soon enough, implementing any new feature is impossible without breaking anything else. And it takes a month.
    • phendrenad2 6y ago
      I actually think that fragility and the things people actually call tech debt are two different things. No one cares if an architecture is perceived as clean and elegant, but takes a long time to implement anything (due to many levels of abstraction and indirection). Just as long as it's (perceived to be) clean and elegant! Tech debt is unfortunately rarely measured or quantified, it's usually a gut instinct.
• neltnerb 6y ago
  If no one in the car factory remembers what the paint sprayer was set at, they will make a giant mess. Any definition of technical debt should encompass more than the narrow field of software engineering. I also like this definition, with the caveat that technical debt should also include things like using a "good enough" solution and being forced to use it for a long time after it becomes counterproductive because you don't want to allocate the resources to switch. Say, a payroll provider as a simplistic example.
• honestduane 6y ago
  I normally use a business and finance metaphor to explain technical debt as "Technical debt is a debt with a personal guarantee, financed with priority, that also has a balloon payment. It can also be called at any time, suddenly, with no warning."
• nautilus12 6y ago
  This is part of the reason why I like type driven programming because it forces you to suss out all those edge cases up front and avoid most major debt altogether but it gets carried away too often. More of an ideal...
• louwrentius 6y ago
  The author is on to something, but still, most cases of technical debt aren't really technical debt as how Ward Cunningham meant the concept. His idea is to regularly pause, and take your time to incorporate your new knowledge about the problem at hand into your code. There is no other way, because if code concepts don't reflect the problem space, development will slow down, become cumbersome. But what I see and what a friend of mine observed: - Most technical debt is just bad code - Most technical debt is just mistakes - Most technical debt is just a lack of basic mainteance. Why call that technical debt? What does the term teach you or anyone else? https://louwrentius.com/most-technical-debt-is-just-bullshit.html https://louwrentius.com/most-technical-debt-is-just-bullshit...
• jariel 6y ago
  I'm not so sure if it's 'lack of understanding' of some other tech. And it's not 'debt' or rather, only debt in a certain context. It's highly rational to expend minimal energy trying a new feature, because time to market is key, and so is the fact that there's a good chance nobody will want it. 'Debt' is only ostensibly incurred once the feature actually works, thus there's real material value to be gained whereupon the ostensible refactor becomes impending, and therefore seen as 'debt'. The 'debt' didn't materialize in a bunch of other things because they were dumped. I also don't think anyone has too much trouble with understanding this, the operational issue is that 'technical debt' will always be put alongside 'shiny new feature' in terms of priority, in which case it becomes much less amenable for investment. To put another way, and this hurts all of us Engineers at a deep level: The most efficient perpetual state of code may be messy, unfinished and have bugs outstanding. Just let that one sink in: in a situation of ongoing feature development which yields benefits to userland, the optimal level of 'completeness' of most code is literally 'never really complete'. Bugs and ugly architecture likely represent a more efficient operating state when we consider value creation as the real goal. The more 'core' and longstanding a bit of code is, probably it makes more sense to go after the technical debt because the yields of the effort are pervasive. But for many other things, nope. If you're building a home to last 500 years (ie Europe) you want a solid foundation, if you're building it only to last maybe 50 years before they tear down and put up something new, then some things are less important.
  • spfzero 6y ago
    But during the 50 years, you are probably paying in a lot of little ways for the less robust system. In my experience that takes the form of 5 engineers working for two weeks to accomplish something one engineer could do if he/she fully understood the system. Not to mention work done fixing bugs that would never exist in the system with a solid foundation.
• deleted 6y ago
  [deleted]
• jmorrison 6y ago
  "Technical Debt" seems a trite, overly simplistic, if not downright misleading metaphor. No other engineering discipline uses metaphor (as does software "engineering"). They all use analysis. An in-all-ways superior, analytical model you really ought to know is outlined here: https://witseie.github.io/software-dev-3/docs/lehmans-laws.pdf https://witseie.github.io/software-dev-3/docs/lehmans-laws.p... RIP, Professor Lehman
• GCA10 6y ago
  The analysis here is so spot-on that I'd argue it sometimes applies even to Wikipedia as well. (OP offers up Wikipedia as a service that can "reorganize to reflect its understanding" of what's changed as new features keep getting added.) Often, yes, especially on relatively simple pages that relate to geography, mildly famous people, etc. But take a look at Wikipedia's page on Facebook, which is now a 539-source accretion of diverse headlines as they happened, now held together only by subject headers that are the digital equivalent of very large paperclips. Or a ship's log. Fixing this would be brutally tough! We're talking about what's now a "semi-protected article," alterable only by trusted players, because otherwise it's more likely to be defaced than improved. In fact, looking at the Talk section for the Facebook article, it looks as if it was deemed a "good article" from 2006-2011 but then lost this status. A telling comment at the time: "Compared with the latest reviewed version of the article, the prose is very choppy and unclear. In some sections, every sentence seems to function as its own paragraph, while in other sections there are random paragraph separations where there shouldn't be. The entire Website section is a mass conglomeration of Facebook features that needs to be sorted out in some way." What's visible now is beyond the stage where incremental fixes (or additions) can fix things. Meaningful improvement will come only from a top-to-bottom rewrite and rethinking of the article, so that Facebook's role, history and features are presented with the clarity and insight of author(s) who can put all the pieces together in a framework that's strong enough to overcome the "ship's log" problem.
• mattdeboard 6y ago
  Very interesting & useful framing of technical debt as epistemological issue! Creating records of what we know and also creating a system that ensures future generations can understand those records is pretty much all the difference there is between us and other animals. I've been thinking a lot about this lately wrt education, so this post is hitting me in stride.
• bluedino 6y ago
  “We are too busy building new things. We can’t spend time fixing/improving/etc” That’s the excuse I hear every time. And they always fail to see, if you fixed problems or improved things, you’d get more time.
• Guthur 6y ago
  The team tech debt had never translated well to any stake holders be they management or product. Recently I've made the decision to frame all of this as reliability problems. My message is that if you want engineers to provide 24/7 support, which they invariably do, then you must allow them to work on the reliability of system as they see it, they are after all now in a way a customer of that system in terms of their work life balance. I have not yet had to say we can no longer support a system 24/7, we'll see how it goes.
• rtp 6y ago
  Software development looks a lot like evolution. The market and business requirements are the environment that weeds out the unfit software. Adapt or die. Codebases that are slow to adapt to outside changes are like species that are slow to adapt to selection pressures. So like the vestigial organs bursting from infection, so are companies that are unable to ship because devs are slowed down by messy code.
• username90 6y ago
  When someone comes to you saying they have a problem with technical debt, do you actually have technical debt? Or do your team just have a case of technical hubris? If your team isn't capable of writing a better system then you don't have technical debt, you just have an expensive system or a poor team. Telling the difference between technical debt and technical hubris is hard, and giving in to technical hubris is much worse than living with technical debt since technical hubris is mostly just a every expensive way to create technical debt.
• abunuwas 6y ago
  Every time you add a new feature you're basically creating technical debt in one way or another, often in a way which is not obvious until you've built a few additional changes on top. It's best to refactor a bit with every new code change. Most people I know never refactor, always say they'll do later, and then end up asking for permission to rewrite the whole thing, only to make a new mess
  • jspiral 6y ago
    this matches my experience as a developer. now as a manager, i treasure those who can build most of their refactoring in as a "tax" onto every task, and then explain anything bigger that won't fit clearly enough - we can usually find a future initiative that could expand to contain and benefit from the desired refactor if it's actually a good idea.
• wwarner 6y ago
  I love this idea. It's like saying that entropy is a measure of ignorance. I wonder if you could apply a similar argument to develop a quantitative description of tech debt.
• ezoe 6y ago
  The ugly code can be dealt with. But we can't dealt the ugly environment. The most severe technical debt is the environment, that is OS, toolchains, framework, library, were fixed at the time development started. Updating the environment shall be part of the cost of development, but we tend to ignore it for more present short term gain, burden the cost to the future self. Within a few years, the environment is too old to work with. We have to deal with the bugs that were fixed years ago in upstream, reinvent the features that was also present in the upstream. 5 years past and we seriously consider updating the environment but since there was no update, existing code relies on old behaviours so we have to fix all of them but that doesn't introduce any short term gain so updating was abandoned. 10 years past and software is dead.
• flippinburgers 6y ago
  Technical debt of any significance is a product of poorly organized data. If the way you construct your data relationships is poor the product will be poor. This includes how different api speak to one another on a data level. All other kinds of debt can be refactored slowly over time if the individual refactoring knows what they are doing.
  • dragonwriter 6y ago
    > Technical debt of any significance is a product of poorly organized data. Except on the level where code is data, and so is basically everything else, this is not true. > If the way you construct your data relationships is poor the product will be poor. Probably, but that doesn't support the prior claim in any meaningful way. > All other kinds of debt can be refactored slowly over time if the individual refactoring knows what they are doing. So can APIs and other forms of data organization. It may be somewhat less common for people writing code to be proficient in some aspects of data refactoring, but that doesn't change the fact that it can be done. That refactoring can be done incrementally — that it is possible to pay down tech debt — doesn't, in any case, prevent it from being significant.
• dfilppi 6y ago
  Technical debt is a sign of success in the best case. It means you had to rush out changes to satisfy possibly shifting customer demand. Few businesses have the resources to devote to technical debt reduction vs new features or new products.
• lowbloodsugar 6y ago
  Can we stop using the term Technical Debt? First objection: Managers and Business persons understand Debt, like it and use it. I use credit cards and have a car loan. If we, as engineers, present the problem as "You can have what you want now, but you will incur Technical Debt" then any sane person will say "Sure! Good deal!" Ask yourself, how many times a manager or business owner has asked "What is the interest rate?" Zero times. Even if you really want to call it Debt, don't. Even if you could convince me that Debt really describes the problem, I would suggest that you don't use that term. You are using it because you want to better describe a problem and reach an understanding, and achieve a goal. However, the managers will listen to what you said, agree that it describes the problem, and the proceed to go in the exact opposite direction that you wanted. Calling it Debt does not achieve your goals. You can keep calling debt because it's oh so clever a phrase, but see where it gets you. Second Objection: It's not debt. Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need". Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work. It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year. Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well.
  • nullsense 6y ago
    Would you have any objections to the term "Technical Tax" in it's place? The way I see it, the cruft always removes some % of your capacity to deliver. Once your technical tax bracket gets too high you have no capacity left over to make forward progress. It's not a perfect metaphor by any stretch but what I think it gets right is that it's a reduction to your capacity to deliver that you pay in perpetuity.
• Geminidog 6y ago
  Tech debt is always described as a metaphor. The word itself is a metaphor for something ill defined. The problem with the metaphor is that a vague definition of the problem means that there will be equally vague solutions. No one is really sure what tech debt is exactly. There is a formal property to the program that correlates with our level of understanding of the program and our ability to change the program with limited understanding. You give a metaphor of a kitchen to help someone understand the problem. To solve the problem I give another metaphor: Wash the dishes and scrape the grill to prevent technical debt. Does that help you understand the solution? No. It gives me nothing. The solution is as ill defined as the problem. There is another phenomenon that the kitchen metaphor fails to describe. The failure is this: All measures to prevent technical debt will fail given enough time. Technical debt can be eliminated but it cannot be prevented. Even if you try to write the cleanest code and you're given unlimited time to organize your code, all of your attempts at prevention will fail. How do I know this? Because the most insidious form of technical debt is always unexpected. People may take shortcuts here and there but those shortcuts aren't taken with the knowledge that there will be huge problems down the line. The worst technical debt always appears as mistakes that weren't known. A shortcut taken now can be valid and never lead to problems in the future. Technical debt that actually causes serious issues exists only in hindsight. What is the formal definition of Technical debt? The set of all code that isn't a combinator.
• tuddman 6y ago
  I stopped using the term 'technical debt' with non-technical people a long time ago to describe needing to maintain code. One guy even tried to convince me he was correct that the term is BS because, 'he heard from some other <unnamed> guy that technical debt is programmer BS code-speak for wanting to work on pet projects, and not what the business wants or needs.' And that he should ignore anyone who tries to tell him otherwise. Ignoring the fact that if development slowed to a crawl, basically the company would fold and we'd all be out of a job. Anyway. I liken maintaining code to maintaining a car/engine. The engine/pit crew analogy has worked well on more than a few occasions: - We're trying to keep this thing running, right? - We want it to run fast, and be impressive, right? - We want to be able to corner quickly, right? Well, when's the last time you had an oil change? If there's a bunch of gunk in the engine, and we're carrying this 1000lb load of sugar that that one customer asked us to carry, how fast do you think we can go? If we tend to the engine, we can keep it running smoothly, if at all. So, we have a choice: Do we (a) take it to jiffy-lube once every 5 years, or never because who wants to invest in maintenance? and let that one kid who doesn't know what he's doing change the oil? Or do we (b) let an experienced pit crew tune, monitor and clean the engine and tires regularly so we can fly around the track and win races and make lots of money? You like cars, right? Hopefully you get it. You decide.
• panic 6y ago
  Programming as Theory Building by Peter Naur is a worthwhile read on this subject: http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf
• jeff-davis 6y ago
  The problem with analogies is that software is fundamentally new. It's not debt where you can just pay it off after the launch. It's not a mess where a cleaning crew can have it taken care of in a day or a week. It's not a structure that will collapse because you added one too many storeys. Software takes all the guardrails off of complexity. A swiss watch is a mechanical masterwork, but the complexity is limited because you have to fit the gears into a limited space. Everything else we deal with has some kind of pushback on complexity, with the possible exception of biological systems that take millions of years to change. Software can grow in complexity with no obvious bound. You can tackle any one particular bug with an extra branch to say "don't let this happen". But a gigabyte of branches is a hell of a lot of complexity. Software engineering is an attempt to wrangle that complexity through all kinds of strategies from "architecture" (another poor analogy) to type systems and OOP and FP and the actor model and everything else. Technical "debt" is really the mismanagement of complexity. It's hard to understand the costs because the costs are inherently unknown unknowns. If you mismanage complexity, then all estimates are meaningless because at any point you could hit a never-ending fractal of problems. It might be completely intractable to add any significant new feature. Developers want to ship features, call it a job well done and take some time off for Christmas. When working with technical debt, no matter how smart the developer is, it's really just luck of the draw who hits a fractal of problems and never finishes and who doesn't and converges on a solution (and when it's bad enough, the latter just never happens).
• robbiemitchell 6y ago
  Building a software product is like building a lemonade stand that is on its way toward something bigger -- maybe a restaurant, maybe a stadium, who knows. At every step, it needs to be usable for making money. There's no up-front blueprint, no predictable audience or revenue. You figure it out as you go. Looking at something like a physical building, it's obvious that as you figure out what people want and where you need to build, you need to refactor. The plumbing, electrical, HVAC, etc. you need for one phase can be extended... until they can't. Everything needs to be rebuilt along the way. It's R&D, but also needs continual care if you're growing fast.
• avindroth 6y ago
  Technical debt is a very useful term for talking about a similar concept for the mind: psychological debt. If all you do is learn and learn and you don’t reorganize what you have learned (through proper introspection and reunderstanding), soon enough you will become very rigid. Meditation is one way of dealing with psychological debt...
  • AlexCoventry 6y ago
    What kind of meditation?
    • avindroth 6y ago
      Simple breathing meditation or mantra meditation would still work. Any form of meditation that isn't too forceful.
• jameson 6y ago
  But does it matter? If a company's able to meet the revenue target with a shitty code and hire enough engineer to bandage the code to and be able to meet the next target, that's good enough, right? Who cares about code quality or best engineering practices? As long as company grows which in turn, my compensation grows and if I retire sooner than planned, then that's great, right? --- Sadly, I think this is the truth in many of the tech companies in the Bay Area. I've seen too many times why managers can't understanding such a simple thing takes too long. Common problem the blog explains already is the 'go-go-go' product cycle. A dirty hack is applied to the code base to solve the problem quick but it'll make code less easier to evolve. Another problem I've seen is projects led by opportunists. There are engineers who build projects just good enough to solve the problem, gets all the credit before there's enough soak time for the new shiny FooBar application and jumps to a new company with a new title and higher comp. The FooBar starts to have issues but the core developer is no longer with the company. Company needs checks to make sure these opportunists don't go wild. --- My reason for trying to reduce tech debt regularly is simple: Learning dirty code at company X gives no value to me for a long run. Also trying best to write clean and manageable code is something I honor as well enjoy doing it. But... interestingly enough, I started a job at a company recently and code here is one of the worst I've seen in years. Copy-pasted codes, implicit behaviors where a code change is pretty much a whack a mole game, zero automated testing, no local testing, list can go on. However, company's doing fantastic business-wise. Exceeding revenue target every time which in turn, we can just increase more head counts to write code on top of it just enough to make it "functional". so... does the tech debt matter?
  • cuillevel3 6y ago
    It's a ponzi (pyramid) scheme. I think there are ways for the company to escape that scheme, maybe by investing into other fields, outsourcing, buying growth and such. I still find it risky, especially if you join late.
• antpls 6y ago
  Development is only a step of the whole process of selling a good. One must consider the entire pipeline, from sales to QA, in order to understand where are the bottlenecks. At one point, _if_ technical debt becomes a problem, non-tech people will pin-point this cause, and they will ask for either mitigation or resolution. When found, the entire pipeline should be made aware of the bottleneck, because some small changes at some steps could lead to huge gains in other steps. Example : "if ops could do this thing, we could remove the entire library from the codebase" (ops), or "that feature was actually never used" (customer feedback), or "if we can get the customer to accept this alternative, we wouldn't need this piece of complicated sub-feature" (need sales) Then, even the smallest change could impact all other steps such as tests, documentation, reviewing, sales, QA, etc Personal preference : I would rather hire developers who ship the requested ticket/story, rather than "fixing tech debt" under the hood. To drive the entire company, all its parts must correctly report and correctly execute. Edit : from the article , “We’re in a build the plane while flying situation, how can we get this out now without doing a big rewrite?” is exactly what non-tech people would ask, because they can take action to mitigate at other steps of the process
• deleted 6y ago
  [deleted]
• aklefdal 6y ago
  I would also recommend this talk by Einar Høst: Technical debt isn't technical https://youtu.be/d2Ddo8OV7ig https://youtu.be/d2Ddo8OV7ig
• JohnL4 6y ago
  I wonder if an intermediate step between "not understand what the code is doing" and "modify the code to reduce technical debt" might be "do some archaeology and document the discoveries (preferably, in the code itself)"?
• jackmarty5 6y ago
  I am dipping in debt for so long until i came across with RICH SKRENTA who set me free from old debt and increase my credit score plus took away all bad inquires on credit report within a short period of time without any stress. CONTACT INFORMATION: richskrentacyberservice@gmail.com and via text (440)459-0850