26 ms·

Technical Debt: Why it'll ruin your software

204 points by yannikyeo 6y ago

Hokusai 6y ago
> Payments couldn’t be processed in different currencies > If the delivery system is offline, the code wouldn’t work > Users with deactivated accounts could still access the system > No automated testing > And this, my friends, is what we know as Technical Debt. I do not describe that as technical debt. That are mostly lack of features. The code could be fantastic and it is just that to support different currencies, disable accounts or similar things new code is needed. The lack of automated testing is more in line on what I think that it is technical debt. Details aside it is an interesting read.
- bananaface 6y ago
  I wouldn't even say lack of testing is technical debt - it's just another feature that isn't implemented. Once you implement it, problem's solved. It doesn't make the system worse/more expensive as it grows, and it doesn't become more costly to "fix" the bigger the system gets. IMO those are the operative features of tech debt.
  - yoz-y 6y ago
    If you always have a perfect vision of your software and the team is very small then I would agree. (I.e.: I don’t write tests for my hobby projects) But testing is mainly important so a developer not familiar with the program will not break it by modifying something seemingly unrelated. Lack of tests will absolutely bite you.
    - bananaface 6y ago
      I agree, I just wouldn't call it tech debt. It doesn't become more expensive to fix over time, except for the bump when you forget how the original code works. There's no metaphorical "interest" that you draw down on.
  - Hokusai 6y ago
    > I wouldn't even say lack of testing is technical deb You are right, it depends on the kind of application and circumstances testing can be done in different ways. There is occasions were instead of automated testing there are other ways of working with quality. But, in this case automated testing is in the list of things that needs to be done. So, I think that to want automated testing and not have them is technical debt.
    - bananaface 6y ago
      I said this below but I like to distinguish technical debt as having metaphorical "interest" - specifically, it becomes more expensive to pay back the longer you leave it, the ball of debt grows over time. It's stuff that gets baked into a product, and then is difficult (or impossible) to un-bake, and gets more difficult the more the product grows around it. Aside from the initial increase in cost when you forget how the original code worked, tests are no more expensive to write in a year as they are today. Not significantly, at least. So I'd just class them as incomplete product - the effects are negative and can be expensive, but it doesn't dig you into a hole.
- LASR 6y ago
  Yeah this is not technical debt at all. These are examples of launch-aborting bad bugs. If we try to characterize the "perfect" example of technical debt: - There is a spec, say: v1, of how the product must behave to the user. - The product behaves exactly as defined in v1. I.e.: There are zero bugs. - The very next iteration (v2) of this product has some cost to achieve. - There is a counterfactual set of decisions that could have been made, which would make achieving v2 have the minimal possible cost. Debt is the delta between the set of decisions made in implementing v1 vs the counterfactual set of decisions not made in implementing v1 that would have made the cost of implementing v2 minimal. This definition has all the familiar mechanics of technical debt. - You don't need to pay the debt to achieve v2 perfectly - it would just be more expensive. - If all you ever want to do is v1, ie: there is no v2, then there is no technical debt, no matter how ugly the code is for v1. - You can choose to reallocate costs between v1 and v2 freely. The distribution of costs will affect launch timelines, but will have no effect on the user-visible quality of either version. It's dangerous not to understand the difference between bugs and technical debt. I lost interest in reading this article after it seemed like the author did not understand this basic difference.
solomatov 6y ago
In my experience, I have seen much more problems because of over engineering by well meaning people than because of technical debt. Simple but under engineered systems are much easier to rewrite than to simplify over engineered ones.
- didibus 6y ago
  I would totally count over engineered a technical dept. Any design choices and implementation choices that make a code base limited in its future abilities to change and evolve, and which causes it to require more time and effort to be understood, I consider technical dept. The dept is that you take time and effort from your future to save time and effort in your present.
  - solomatov 6y ago
    I would call it bad investment not a technical debt. As an investor you could invest in a lot of businesses which fail if we use finance metaphor.
- mrmrcoleman 6y ago
  Agreed. I once worked on a project which was a microservices based system for managing various types of infrastructure. Progress was painfully slow. There was a separate testing client that was used for a lot of the demos. The demos on the 'real system' would fail so often that somebody came up with the idea to just take a lot of the code from the microservices and drop it straight alongside the testing client, as a monolith. It was so much more stable that after becoming the default way to demo, it became the default way to use the tool. 5 years on and I believe it's still running that way. In this case microservices were massive over engineering.
  - 35fbe7d3d5b9 6y ago
    > In this case microservices were massive over engineering. They often are. Well-meaning engineers and architects seem to reach for them while forgetting that microservices are about scaling your organization, not your software. There are very few technical deficiencies in a monolith that are solved by microservices. Indeed, they typically bring technical hurdles: distributed systems are hard to reason through and IPC over the network introduces latency. And you need a very strong ops team to implement them without major headaches. But where they really start to shine is when regression testing takes ~days and your development cycles are screeching to a halt because you've got too many in flight features and not enough runway to land them. What takes real skill is recognizing which of your monoliths should be grown and which ones need to be sliced down the middle.
idank 6y ago
The title the author chose does a bit of injustice to the contents of the post. The post uses a lot of words to describe an understanding that experienced engineers and managers should have. Technical debt is a trade off. It exists in nearly all software of decent size as it's being developed. It is vital both for management and engineers alike to keep it at a reasonable amount, or you'll wake up one day with something that can't release new features, function, scale or be maintained. It is also worth stating that tech debt can have little to no siginifcance to the success of a startup.
- wolco2 6y ago
  Technical debt starts to matter when the initial project changes focus or patches start mountig. These days rewrites are popular. They make sense in some cases (when the project is smaller or introducing new framework). But in others where the original developer and business people have left and no one knows exactly how things work aside from they need to continue to do the same. In those cases fixing technical debt is extremely important. A startup is more likely to fall into the above category if they ignore their technical debt because rewrites are hard and messy.
- Mertax 6y ago
  Seems to me that technical debt needs to be dealt with as a function of the revenue the company/product is bringing in. The wisdom comes from timing the investment so it’s not destroying the “mature” product due to entropy or strangling the new product due over engineering. Startups do seem to have bigger issues than technical debt to deal with. Because relatively speaking, there are bigger mountains to climb early in the startup’s development.
- kubanczyk 6y ago
  It is moreover not entirely unworthy to state that tech debt can have little to no siginifcance to the success of the founder of a startup. /s
spaetzleesser 6y ago
On the other hand a lot of efforts to avoid technical debt end up producing more technical debt because in the end you don't know where things will be going. I think refactoring just needs to be an ongoing effort and should almost never be an explicit task.
mytailorisrich 6y ago
If, for example, there is no requirement to support multiple currencies then there is no need to spend time on designing for multiple currencies "just in case". This is not choosing an easy solution, this is doing just what needed instead of wasting time and efforts on something that may never actually be needed. Now, the design should be sound and follow good practices. This is how to limit the rework needed when new features are added because it is impossible to design to cover all possible future features: Do the minimum but do it cleanly.
anm89 6y ago
I don't buy this concept. It's like saying "Financial Debt: Why it will ruin your company" Yeah it can if you abuse it. It can also be incredibly helpful.
- solumos 6y ago
  Absolutely. There are payday loans (poorly developed systems) that are clearly always a bad idea, and then there are mortgages (well-architected w/ focus on minimum viability) that get you much farther in terms of realized value than you could by saving up for a house (over-engineering).
SkyPuncher 6y ago
I'm being a bit blunt here. It's easy to say Technical Debt will ruin your software when you pick a contrived thing and label it as Technical Debt. > John knew his code had a few bugs. But nearing the deadline, another project appeared and it took a lot of John’s time, so he couldn’t go back and fix the problems. This is a problem, but this is not inherently technical debt. That's just delivering a bad/incomplete feature (Not necessarily John's fault if he's been asked to make changes). Code with Technical debt works or mostly works, but relies on non-maintainable or less ideal than patterns. Simplified example. Adding a "Cancel" Button to a form. This button involves adding a new "secondary" class style to the button. * Technical Debt - Button is in place. Works correctly. Instead of a <Button> component and tweaking it to handle the new "secondary" class. John simply copies and pastes the <Button> code directly into the implementation. * Bug/Bad Feature - John references the button correctly, but fails to handle certain state resets properly when the form is cancelled. ----- The prior is technical debt because it works correctly, but doesn't follow a good pattern or does something unexpected (refactoring that button will be much, much harder). The latter is likely just bad code. The case where the latter is not bad code is if the company has made an intentional decision to not handle cancel edge cases. Even here, I would argue that is product debt - not technical debt. ---- Every software product in the world has debt. Just like every software product in the world has bugs. You need to account for your debt as you grow. Otherwise it will eat you.
- mikepurvis 6y ago
  There's a grey area though, where you properly define a new style (yay) at the time the first Cancel button is created, but then down the road you find yourself with a whole bunch of new styles for things, and it turns out over time that the styles are maybe repetitious or subtly inconsistent or whatever. The debt has become the reality that the initial abstraction ("all our buttons are the same") hasn't kept pace with the needs of the product as it has iterated forward. Paying down the debt is creating new abstractions and updating all the buttons to be using them. The worst case scenario is probably partial paydowns, where the abstractions get changed but some of the non-aligned stuff remains and so that you end up with a jumble. Especially combined with inadequate documentation (or a culture of inadequate documentation, where people don't even look because they don't expect it to be there), the old practices can end up being cargo culted forward even when someone attempted to create a better way.
lxe 6y ago
Just like any debt, technical debt is not "always bad". The point of incurring debt is to make a "large payment" (deliver software) quickly and immediately, in exchange for paying interest over time. If you can deliver a working prototype, scale, get funded, and grow your business quickly in exchange of technical debt, that's not really a bad deal.
6510 6y ago
In the early days of computers the first working version was always so slow rewriting it a few times was an obvious step. You would end up improving a lot of things not necessarily related to speed. I still often crank out a really shitty version that works just to get to the points that require some deep thought. You can get a lot of work done if nothing really matters. The first rewrite is helped a lot by having done things before. The second full rewrite sadly never happens anymore. Just incremental changes.
VikingCoder 6y ago
Bad tech debt will ruin your software, but good tech debt is a smart investment in your business. It takes a good team working together to balance their "tech debt budget" against the other revenue needs of the company. If I've run on Version X of some DB software for a while, and tomorrow Version X + 1 is released, yes, I should recognize that staying on Version X is tech debt. But that may absolutely be the right thing to do for now.
CoffeeDregs 6y ago
Technical debt is like credit card debt: it's high interest; it's not a huge issue if you use it wisely; and you have to track its usage and level against your total code/assets. Like credit card debt, too many people turn around and they've got $20k of credit card debt or 20k LOC of tech debt. I don't have too much of a problem with tech debt as long as: the benefit is clear; the debt is well understood; the payoff date/cost is planned. Just last night I was talking with a developer who works for me: "This way will require 5 queries instead of 1. Can you help me figure out this whacky ORM API to do it in 1?"; "Just do it as 5 right now and, as we learn more about the ORM API, we'll fix it later..." Tech debt: we get the product done faster; we've got a 1-5 line change to make (when we know how to make it); and we'll do so in a few months.
- pak9rabid 6y ago
  >and we'll do so in a few months. Ah, famous last words that I myself have also spoken from time to time.
  - nullsense 6y ago
    Yup. Mentally I pipe everything any devs, including myself, say through a sed command like this: s/for now/forever/g
- heelix 6y ago
  I love this analogy. Dealing with a minor set of updates ... that now need to be done in 60+ all slightly different codebases for this weekend. I'm using it in our next chat with the business side.
- iainctduncan 6y ago
  Yes, this is totally on the money. This is exactly what we want to see when assessing tech debt on an acquisition assessment (I do tech diligence for acquisitions). If you do it for good reasons, and you track it, and you proactively allocate resources on an ongoing basis or make tech debt remediation a first class road map item, it's not a problem, it might even be a good thing. If you wracked it up playing fast and loose and being all "go fast and break things", it could cost you the deal, or millions of dollars off the deal price.
kylegill 6y ago
I like to think of Technical Debt like an accountant or CFO would think about Financial Debt. It provides leverage to incur debt at early stages, incur too much and it can really come back to bite, but a startup that incurs no debt will struggle to grow.
chairleader 6y ago
Interesting. I would say that John didn't build a solution that met all of the use cases that the business needed. * To ensure accuracy of transactions, he should have built reporting to meet the needs of accountants. * To support change, he should have kept his components separate and provided modest testing examples. * To support developers and operations, he should have found and documented the external dependencies along with steps to verify that they are in place. Whether product managers didn't uncover these requirements or the business didn't prioritize them, these aspects of the definition of "done" have more to do with thee environment the engineer is working in and less to do with his or her work.
papito 6y ago
There is bad technical debt and there is acceptable technical debt. The mark of a good engineer is knowing where to cut the corners - which you will always have to do. Hardcoding something in a file rather than pulling it from a config or a database has a pretty good ROI in terms of time saved, and it's not that hard to change later, but tying yourself to, say, a kind of storage that you know is not going to work long-term, that will cost you later. Also, sometimes doing MORE results in more technical debt. If you are going to spend your time building a Kubernetes cluster because "your home page has to be webscale", you are an idiot.
kgilpin 6y ago
Discussion of technical debt always seems to devolve into an augment about what technical debt actually is. Are there specific patterns of code behavior, metrics which can be derived from analyzing code, quality scores that are non-controversial, which can be used to define this problem? Things that can be measured and managed in a canonical way? How can some knowledge of experienced CTOs be distilled so that we can start to automate some of this wisdom?
- bananaface 6y ago
  I would say: technical debt is anything that makes the system more expensive to maintain (and grow) over time, and becomes more expensive to fix the longer you leave it. If it's just a bad or incomplete aspect of the system, that's not sufficient. It has to become more expensive over time. So e.g. lack of functionality isn't tech debt, but a bad abstraction is usually tech debt.
tabtab 6y ago
There is a balancing point between under-analysis and over-analysis. It's hard to know the true requirements until the system is actually in production. You can't realistically pre-learn many domain lessons: you just have to dive in and see what floats by setting sail. Finding the best balancing point is hard to turn into a sure-fire formula. I use experience (age) to make a best guess based on on past successes and failures and project types. One tip is to collect and keep a list of questions and suggestions, and make sure they are sufficiently explored. You can't answer questions that have not been asked, but AT LEAST answer those that are asked. Make sure staff is not afraid to ask questions or make suggestions.
- flavius29663 6y ago
  You have to release the software, with hardcoded inputs, limitations and bugs. That is fine. Having a clean code helps you then quickly polishing it and evolving it based on the customer needs. I prefer that to an over designed system, that is 80% clean and 20% crap, because that is hard to change as time goes by, and that 80% will stay the same, but will become 50% and then 10% of the total codebase.
  - tabtab 6y ago
    Nobody agrees on what "clean code" is. I agree there are rules of thumb most will accept, such as try to be modular (group related things together), manage constants in a table or central class instead of hard-wire them, factor heavily repeated patterns into subroutines/methods/classes, comment at least the "big picture" of sections, and the oddities.
skybrian 6y ago
This would be more interesting if it told us more about what actually happened with the Tower of Pisa.
pryelluw 6y ago
I started to use technical liability and technical asset in lieu of technical debt. Easier to explain and provides more insight into good engineering choices.
- nullsense 6y ago
  I like the metaphor technical tax, as it's the cruft that usually permanently sucks up x% of your development capacity. If it ratchets up permanently, after some time you're at a complete standstill.
mgamache 6y ago
Technical Debt is not a thing when you are coding a new feature. It’s like a stock future. It might be debt, but it might be something no one uses or gets dropped (or rolled into another feature). There’s a cost to speed that has to be considered. Maybe it’s debt, maybe you save the time and spend it on other more valuable tasks.
chandmk 6y ago
One questions I ask myself to bring clarity is, If I am the one paying bills, would I really pay another developer for this refactoring? Yes: Technical debt it is. No: just busy work.
beiller 6y ago
Does anyone have any examples of companies that died because of too much technical debt? For me its kind of one of those things I acknowledge exists but I try to avoid any projects where their goal is purely "decrease technical debt" or even when that goal is on the periphery. And I see that kind of thing way more frequently than you might think!
- Jtsummers 6y ago
  Not a company, but a project. It has not died yet, it is instead being rewritten while the old one is on life support. The technical debt accrued due to: 1. Poor code practices (C++, poor use or understanding of pointers and threads created most of the actual errors in the program that make it unstable) 2. Excessive copy/paste (so bad decisions propagated quickly) 3. Poor architecture (didn't scale, performance is technically fine but development costs exploded as new capabilities were added) 4. Poor testing (almost entirely manual, as the system grew this grew with it to the point of creating major delays in releases) They're rewriting it now keeping these lessons in mind. They're surviving because they're part of a larger org that can afford to keep them around for the rewrite, but essentially this now 10-12 year old system is dead. The other reason they're surviving is they happen to have only one competitor, whose product costs 10x as much per seat. So their customers want them to survive if they can hit the quality improvements in the rewrite, failing that they'll be disbanded.
- deleted 6y ago
  [deleted]
hardwaregeek 6y ago
I've become skeptical of people talking about technical debt and clean code and all the standard Fowler/Uncle Bob/PragProg-isms. Not because they're wrong. If anything they're all right, but in a rather vacuous, well-yeah way. Yes technical debt is bad. Yes we should start with a design. Yes we should do refactoring. But using the analogy of the author, that's like telling someone who's overweight and eating a lot of junk food that they should "eat healthier and exercise". Well yeah. They probably knew that already. And so many people try to make it a dichotomy. Like that diagram of a project with a design versus without. That's not a fair comparison. What does a design even mean? Wireframes? A written document of features? How do we change this design? What's the way in which we get feedback? And what sort of projects are we talking here? A programming language is very different from a website. And what even counts as no design? Some other notes: - I'm not sure the author correctly used the Pareto principle. It's not just a generic "split things into 80/20" but a specific observation on how 20% of the causes result in 80% of the effects. - The post could have used a quick proofread. There's quite a few spelling mistakes and poorly phrased sentences. I totally get if the author is not a native speaker, but they could easily enlist one to help (if the author wishes, I'd be happy to proofread—contact me). - I get the whole "make this post fun with cats!" but honestly I'd prefer a straightforward example with no funny images. Maybe that's just my grumpiness.
- SkyPuncher 6y ago
  > Yes technical debt is bad. Technical debt is like any debt. It's bad if you come due on it and don't have the resources to pay it off. Unlike cash debts, technical debt rarely comes due in a tangible fashion. If getting to my next round vs. failing means leveraging technical debt, I'm going to do that by all means. It's not necessarily easier to fix tech debt at scale, but having more resources means it's less impactful on bandwidth.
  - nilkn 6y ago
    This is my preferred way of thinking about it too. I wouldn't say debt in general is universally bad, and so I wouldn't say the same thing about technical debt either. Technical debt can save a company by pushing something forward and launching a product sooner than a competitor. It can save a big customer by fixing a bug for them quickly that if not fixed immediately would have caused them to cancel a multimillion dollar contract. It can also eat away at a company if you let it accrue for decades and never pay it down.
psysharp 6y ago
I see an issue in the web industry that there is sometimes an economical incentive to maintain a solution with technical debt. Just ponder the idea that you hire a bunch of contractors to build you a house, and then you keep them on payroll to come back and fix every broken pipe that they installed to begin with. Even if they feel honor for their work the'll soon drift in to ugly insustainable work due to the nature of their incentives. We might need a proper system to hold engineers responsible insted of hiding behind a company, and in the long run be a solution that provides _space_ for engineers, plausibly.
gregjor 6y ago
Much of the discussion and worry about technical debt stems from a few fallacies programmers seem to fall into: 1. Some objectively "right" or "best" way to write software exists. We refer to "patterns" and "best practices" as if those had the force of science behind them, even though at the same time we can't, as a profession, agree on what we mean. 2. Code we (or someone else down the road) has to maintain wasn't written correctly or perfectly in the first place. Programmers tend to hate maintenance work. 3. We imagine that we could write the perfect program if only our managers and customers didn't impose time and budget constraints, or interfere with their stupid product and marketing directives. 4. Failing to write perfect code that lasts forever indicates a failure on the part of the programmer or the team. 5. Perfectionism (a symptom of obsessive-compulsive behavior) and the increasing worry among programmers about how others perceive and critique their code. Writing perfect code that requires minimal maintenance in the future would require knowing that future, and all of the changes to requirements and constraints that will happen during the lifetime of the code. We can only work with the requirements we know, and those we can reasonably anticipate. Trying to code for requirements we don't have is usually called "overengineering," which means something else in other engineering contexts (as a few other commenters pointed out). I have worked in software development for 40 years so I know that almost no one likes doing maintenance work, especially on someone else's code, and especially with languages and tools no longer in fashion. Maintenance programming is often given to new hires and junior programmers, while the senior developers get to write new code and play with the latest toys. This class division among programmers, often expressed in terms of what makes a programmer junior or senior, gets exacerbated by the personal quality of programming. Programming is a craft, not a science, not even engineering, but we forget that and try to express aesthetic preferences in terms of objective quality, even when we don't have agreed-upon ways to measure objective quality of code. Most software has a short lifespan, which means the "technical debt" will disappear when the code gets rewritten or replaced by a SAAS product or the requirements change. Bridges are expected to stand for decades or even centuries. Jumbo jets have lifespans measured in decades. Very few software projects will stay in use that long. I routinely work on web sites that will stay online for less than a year, because they support short-term marketing goals. American companies have an average lifespan of 18 years, and startups are more likely to go out of business (or get acquired) than to stay in business for even a few years, so focusing on building the equivalent of the Great Pyramid in code at a startup or small company in order to avoid "technical debt" is almost always wasted effort. Businesses factor maintenance into the lifetime cost of software just like they factor maintenance (and depreciation) into the cost of buying a fleet of trucks or a truckload of copying machines. It's the programmers who impose unrealistic goals of no/low maintenance and frame that inevitable maintenance work as a failure of the original design or implementation, i.e. technical debt. We should try to do our best work, to make code that works (i.e. meets requirements and doesn't suffer from preventable bugs), and we should try to anticipate likely changes and make those easy for the next programmer. We should stop imagining a perfectly right way to write code, and stop thinking that maintenance work is beneath us, or a sign that the last team didn't know what they were doing. I think programmers would enhance their value and learn a more realistic (and maybe humble) approach to their craft if they didn't think of programming as an isolated activity disconnected from the business and customers/users their code is meant to serve. James Joyce wrote “What makes most people’s lives unhappy is some disappointed romanticism, some unrealizable or misconceived ideal. In fact you may say that idealism is the ruin of man, and if we lived down to fact, as primitive man had to do, we would be better off....” Joyce wasn't talking about programming, but I try to keep that in mind when balancing technical decisions against the larger set of business and customer concerns.
mkl95 6y ago
There are many dimensions to technical debt, but the biggest one 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 manager or by quitting their job.
projektfu 6y ago
Seems like if you want to make that statement (it'll ruin your software) you need more than a hypothetical example. There are some good ones in memory. 1. Netscape Navigator - was such "spaghetti" that they had trouble re-architecting it to allow it to keep up with evolving web standards, and then put everything into Navigator 6.0 which ended up running like a snail. (Second system effect). I'll note that according to jwz, it was written by people working lots of all-nighters. 2. Microsoft Word for Windows. Apparently had a ponzi-like accumulation of technical debt as they kept adding features to the release and writing code that looked technically correct but was known to be flawed, relying on testers to find the bugs they had known they wrote. Took version 2 for the bugs to get ironed out to a usable state. I've tried coding with some open source programs that are mostly being used for a company's internal process that are basically piles of technical debt, but it'd be rude to mention. I'm sure there are other great ones, but now that so much software is SaaS, we're probably not going to hear about it, because the release dates aren't as obvious. To me, eBay appears to be one, as they are trying to remake their web application to be more modern but it has tons of warts all over it.
Justsignedup 6y ago
One thing I'd like to point out: The tower in Piza was leaning, and gonna collapse. Then an architect devised a way to fix it. They of course said "hell no" because literally the only thing going on in Piza is the tower. To fix/destroy it would destroy the entire economy in Piza. So instead they chose to lift/stabilize it.
slumdev 6y ago
The problem with "technical debt" as a meme is twofold: It's a lousy analogy, and people tend to label absolute garbage as "tech debt". The garbage is not a tool to enable quick growth. It's not a shortcut. It's just garbage. "Technical debt" conversations usually go something like this: Me: "Could we spend a few hours getting a handle on what the data model should look like? Maybe rough out a crude ER diagram?" PHB: "Oh slumdev, you're such a Boy Scout. Just blam it into a document store. If something changes, we'll just be Agile about it. Technical debt is a tool!"
- Aeolun 6y ago
  Cue 300% increase in development time.
  - Viliam1234 6y ago
    Overtime and on-call duty come to save the day.
    - Aeolun 6y ago
      Ah, yes, if we just work 160 hours per week we can just about get it done at the originally estimated time. I guess that means you can take an hour long nap every day to recover before your next shift.
chmod600 6y ago
I don't think debt is really a great analogy. Lot's of people are comfortable with debt, if nothing else. I think it's more like a rushed major remodel of a house. It's kinda bad, but there's really just no practical way to fix it without a teardown.
- nullsense 6y ago
  Yup. It's actually technical tax.
karmakaze 6y ago
> Let’s dive deeper into the problems of John’s code: - Payments couldn’t be processed in different currencies - If the delivery system is offline, the code wouldn’t work - Users with deactivated accounts could still access the system - No automated testing > And this, my friends, is what we know as Technical Debt. Why? Ah no, this is what is known as a broken software development process.
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. 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.
- dredmorbius 6y ago
  Cunningham makes a convincing case for the teerm: https://youtube.com/watch?v=pqeJFYwnkjE https://youtube.com/watch?v=pqeJFYwnkjE (4m44s)
  - lowbloodsugar 6y ago
    He made a convincing case for why its like "debt", but he fails to make a convincing case for its use, or any case at all that using the term has a positive impact on a team's success. He even calls out that some teams think they don't have to pay back the debt. I think that is the norm, and that's the problem of debt. When financial people use debt, that debt comes with structure and consequence: it might be monthly payments or it might be due sometime in the future. Offer such people a "debt" that has nobody enforcing it, nobody quantifying it and of course it wont be paid back. Agile engineers making scary "booga booga" noises about "we need to refactor" just don't carry the same weight as not being able to make payroll because your note is due. And yet that seems surprising to engineers.
jpswade 6y ago
I think this assumes you want to write perfect software, when sometimes it just needs to be good enough.
intricatedetail 6y ago
I find it fascinating that buggy product is considered as delivered. That is the root of the problem.
BobBagwill 6y ago
There are an uncountably large number of pathways one's efforts toward a goal can take. Given that the future is unknowable, any decision one makes can turn out to be an inconvenient (not necessarily wrong) decision. That is "technical debt". It is unavoidable. If you are ignorant of the possible consequences of decision, or choose to ignore or hide them, that's something else.
RandyRanderson 6y ago
IMO, a more pernicious form the tech debt starts with one system. A second person comes along and builds their own system/software b/c of some real or perceived issue with existing software (for example someone thinks something is poorly designed or not the right(tm) technology, etc). This second system then forces integration, APIs, TCP connections between apps. No big deal, right? But the next person comes along and says "I don't like those systems - I want to put tech3 on my resume (a little resume oriented architecture, anyone?) and they build a 3rd system. Now it's really hard to develop features across those apps. One has to be an expert in all those techs. Integration becomes 80% of the work. Now ppl have to create new or buy software just to get anything done. And so it goes. There's a name for this, used a lot on this site.
drbojingle 6y ago
You know what ruins software? Refactoring old stuff you don't like so the code base is "nice", which incidentally introduces 100 bugs that didn't need to exist, pushes deadlines back cause someone has to fix those bugs, and loses customer confidence to the point that investors and customers don't care anymore and then you have no one to build for (but at least your code base is nice and scale-able, to bad 10 x 0 customers is still 0). I've seen more issues because of nonsense like that, or people insisting that code should be DRY and making ridiculous mental contortions in the name of a three letter acronym, or personal taste (the amount of fashion in software development is insane) but I've yet to see a project truly fail because someone cobbled something together quickly, and introduced tech debt. So far anyways.
- nullsense 6y ago
  Part of a codebase I work on suffers from a quality hotspot where half of it got rewritten so it was "nice" and the other half was so hard to reason about it stopped them dead in their tracks and it has persisted in this Frankenstein state for a reasonably long time. On a project with an external deadline this year I had to make some modifications for compliance reasons. It was very painful. The parts that are rewritten are conceptually a lot simpler. They fit in my head. The parts that didn't get rewritten have incredibly high cyclomatic complexity and really don't fit in my head. I want to refactor it so it's nice. I also don't want to introduce lots of bugs nor push out deadlines. A decision was made upfront that we would try to extract this component out of the main system, so it could be independently modified and deployed, as the capability to do so would actually provide decent business value. Sadly this particular decision didn't turn out well, and really, really pushed the deadline. Ultimately we spent about 70% of the engineering effort on the project trying to extract some functionality. I'd say about 10% of is actually extracted. So now it's even more of a Frankenstein split across 2 codebases now. The project is coming to a close, and we will have a clean up session early next year. Our next project is related to this particular component also, so there is scope for us to be making changes to it. The goal is to make this component more stable for customers, and safer to deploy. I think a big bang rewrite is 80% likely to fail. I strongly suspect it's actually worth succeeding at though. I'm trying to chart a path through to a successful reworking of this critical subsystem. The first failure was quite humbling, but not unexpected. Probably the best move I made on this project was getting good logging in place so I can tell exactly what it does, and made it a lot easier to reason about whether our attempted extraction does the same thing. Also I've managed to collapse some of the cyclomatic complexity, so it's easier to mentally keep track of as you're trying to read the code. It's still very, very hard to modify the functionality of the old stuff. My current line of thinking on the best way forward is to abandon the attempted extraction, and repatriate that functionality to the main codebase. Then use characterization/approval tests and finish the original rewrite. I'd be happy to do it piecemeal too, even one ticket a sprint spread out over the course of the year, so long as we actually complete it. In addition I'm planning to try a a tiny, reversible experiment at a different way of extracting it that's much more likely to succeed and deliver the benefits we're looking for while simultaneously charting a way forward on another major piece of tech debt that causes a lot of stability problems. If that experiment succeeds I want to extract all of it that way, and would only attempt to do so once the entire thing was in a reasonable condition first. Getting it all the way to that state would represent a major win in my mind. It's hard when we can't afford to fail at this, and we're not likely to succeed. Really trying my best to find a viable plan. At the same time, if it ain't (that) broke, don't fix it right? But that leaves no road to new capabilities for us as a business. Software is just a hard problem.
phendrenad2 6y ago
I've never seen a project or company killed by tech debt. I've seen projects and companies killed by obsessive-compulsively trying to eliminate it. YMMV
salt-licker 6y ago
This article lacks nuance around the tradeoffs inherent in shipping complex software at maximum velocity. Much more useful is evaluating the long-term impact of specific instances of technical debt, particularly “contagion”: https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxonomy-tech-debt
iainctduncan 6y ago
Assessing tech debt is basically my job these days, as I'm an architecture and infrastructure consultant for technical due diligence on acquisitions, mostly by PE firms. Some fun things you might not know from the field of technical due diligence: - Your startup is much more likely to succeed by being purchased by a private equity fund than anything else these days. Most tech acquisitions are now PE, like over 75% of big ones. (Even up to north of a billion) - The PE fund will send a diligence team. Depending on who they hire, your diligence team could be clueless consultants with checklists, or they could be real hackers who will look at your code, ask all the hard questions, and know a lot about tech debt. They will talk to you for many hours about tech debt. We typically interview for 12 hours and ask for a lot of metrics and docs. We do this for a living, so we're pretty good at sniffing out BS and knowing how to get devs to talk about their software realistically. Most devs are pretty happy to talk shop once they know we are actually developers who have been through the same process ourselves. Sometimes I feel like it's more like Developer Therapy. :-) - If you have bad tech debt, it won't necessarily sink a deal. Deals usually go through or not on other reasons, like business model revenue numbers - stuff that can't be fixed with the application of cash. However, we make a table for them of estimated cost to mitigate debt, and that can be serious cash. (i.e. X extra senior devs and QA for Y months/years) - This cash will come off the price. Or as Amazon apparently puts it... "a haircut". A haircut can easily run over a million on even a small company. So the money saved on devs for the years of accruing debt just comes off the acquisition price, but with a terrible interest rate. Also of interest: we don't actually say it's always bad. We differentiate between intentional and unintentional debt. If you accrued debt to get to market quickly and are then doubling back to attend to it reasonably, that can be a very smart decision and may actually reflect well on the assessment. On the other, debt accrued because the founders only hired interns and new grads and let them run the asylum for years does not. If I were to encapsulate in one sentence what I've learnt about tech debt in the last two years and 50 odd companies examined it would be this: nobody saves money by trying to hire mostly junior developers. Nope nope nope nope nope. If you are running a start up, you need at least a couple of six figure salary, 5+ years experience devs, and a CTO or lead architect with like 10+ years or who really, really knows their stuff. Do not cheap out on this! At a guess, I'd say it's the most obvious differentiator between the hits and the really big haircuts. That said, I only look at companies who have gotten pretty far, so the main differentiator is likely different at early VC stage. We're basically doing the first exit, and if we're talking to you, you have a successful business that some professional big time investors want in on. Hope that's of interest to some folks! :-)
voodootrucker 6y ago
What a garbage article with too many cats.
nojvek 6y ago
Technical Debt only really counts if you have to pay interest on it. Many times I see new engineers wanting to re-write old working code in their new favorite language. My litmus test for technical debt is things we should have done a while ago, but since we didn’t it’s hurting us. Continuing on same path will hurt even more. Better to fix the pain and then move on. Working code that does what it needs and doesn’t require much maintenance is great code. Old != technical debt.
yenwel 6y ago
I've worked on two seperate old code bases with pms who read the lean startup and they believed that technical debt does not exist. Seriously aggravating the situation thus. They did not seem to understand that the main thesis for that book is assuming that you have one in a million change of becoming a unicorn or selling the company to another party and cashing out.
jesssinnss 6y ago
Technical debt is not a thing. It’s made up by people who want things done in a different way than they currently are. All currently good design recommendations will become wrong ones in the future. Today’s best practice is tomorrow’s technical debt. There is just code that works and makes the company money, and code that doesn’t work. Code that is readable and code that is not readable. Starting out with “the right design” will become the wrong design when the market changes and the specs change under your feet. Moving fast and making software that meets market needs requires going back and finding parts that need to be consolidated. It’s just how building software in the non-trilllion-dollar-company-or-in-academy world works.

204 points by yannikyeo 6y ago

> Payments couldn’t be processed in different currencies > If the delivery system is offline, the code wouldn’t work > Users with deactivated accounts could still access the system > No automated testing > And this, my friends, is what we know as Technical Debt. I do not describe that as technical debt. That are mostly lack of features. The code could be fantastic and it is just that to support different currencies, disable accounts or similar things new code is needed. The lack of automated testing is more in line on what I think that it is technical debt. Details aside it is an interesting read.

bananaface 6y ago
I wouldn't even say lack of testing is technical debt - it's just another feature that isn't implemented. Once you implement it, problem's solved. It doesn't make the system worse/more expensive as it grows, and it doesn't become more costly to "fix" the bigger the system gets. IMO those are the operative features of tech debt.
- yoz-y 6y ago
  If you always have a perfect vision of your software and the team is very small then I would agree. (I.e.: I don’t write tests for my hobby projects) But testing is mainly important so a developer not familiar with the program will not break it by modifying something seemingly unrelated. Lack of tests will absolutely bite you.
  - bananaface 6y ago
    I agree, I just wouldn't call it tech debt. It doesn't become more expensive to fix over time, except for the bump when you forget how the original code works. There's no metaphorical "interest" that you draw down on.
- Hokusai 6y ago
  > I wouldn't even say lack of testing is technical deb You are right, it depends on the kind of application and circumstances testing can be done in different ways. There is occasions were instead of automated testing there are other ways of working with quality. But, in this case automated testing is in the list of things that needs to be done. So, I think that to want automated testing and not have them is technical debt.
  - bananaface 6y ago
    I said this below but I like to distinguish technical debt as having metaphorical "interest" - specifically, it becomes more expensive to pay back the longer you leave it, the ball of debt grows over time. It's stuff that gets baked into a product, and then is difficult (or impossible) to un-bake, and gets more difficult the more the product grows around it. Aside from the initial increase in cost when you forget how the original code worked, tests are no more expensive to write in a year as they are today. Not significantly, at least. So I'd just class them as incomplete product - the effects are negative and can be expensive, but it doesn't dig you into a hole.
LASR 6y ago
Yeah this is not technical debt at all. These are examples of launch-aborting bad bugs. If we try to characterize the "perfect" example of technical debt: - There is a spec, say: v1, of how the product must behave to the user. - The product behaves exactly as defined in v1. I.e.: There are zero bugs. - The very next iteration (v2) of this product has some cost to achieve. - There is a counterfactual set of decisions that could have been made, which would make achieving v2 have the minimal possible cost. Debt is the delta between the set of decisions made in implementing v1 vs the counterfactual set of decisions not made in implementing v1 that would have made the cost of implementing v2 minimal. This definition has all the familiar mechanics of technical debt. - You don't need to pay the debt to achieve v2 perfectly - it would just be more expensive. - If all you ever want to do is v1, ie: there is no v2, then there is no technical debt, no matter how ugly the code is for v1. - You can choose to reallocate costs between v1 and v2 freely. The distribution of costs will affect launch timelines, but will have no effect on the user-visible quality of either version. It's dangerous not to understand the difference between bugs and technical debt. I lost interest in reading this article after it seemed like the author did not understand this basic difference.

solomatov 6y ago

In my experience, I have seen much more problems because of over engineering by well meaning people than because of technical debt. Simple but under engineered systems are much easier to rewrite than to simplify over engineered ones.

didibus 6y ago
I would totally count over engineered a technical dept. Any design choices and implementation choices that make a code base limited in its future abilities to change and evolve, and which causes it to require more time and effort to be understood, I consider technical dept. The dept is that you take time and effort from your future to save time and effort in your present.
- solomatov 6y ago
  I would call it bad investment not a technical debt. As an investor you could invest in a lot of businesses which fail if we use finance metaphor.
mrmrcoleman 6y ago
Agreed. I once worked on a project which was a microservices based system for managing various types of infrastructure. Progress was painfully slow. There was a separate testing client that was used for a lot of the demos. The demos on the 'real system' would fail so often that somebody came up with the idea to just take a lot of the code from the microservices and drop it straight alongside the testing client, as a monolith. It was so much more stable that after becoming the default way to demo, it became the default way to use the tool. 5 years on and I believe it's still running that way. In this case microservices were massive over engineering.
- 35fbe7d3d5b9 6y ago
  > In this case microservices were massive over engineering. They often are. Well-meaning engineers and architects seem to reach for them while forgetting that microservices are about scaling your organization, not your software. There are very few technical deficiencies in a monolith that are solved by microservices. Indeed, they typically bring technical hurdles: distributed systems are hard to reason through and IPC over the network introduces latency. And you need a very strong ops team to implement them without major headaches. But where they really start to shine is when regression testing takes ~days and your development cycles are screeching to a halt because you've got too many in flight features and not enough runway to land them. What takes real skill is recognizing which of your monoliths should be grown and which ones need to be sliced down the middle.

idank 6y ago

The title the author chose does a bit of injustice to the contents of the post. The post uses a lot of words to describe an understanding that experienced engineers and managers should have. Technical debt is a trade off. It exists in nearly all software of decent size as it's being developed. It is vital both for management and engineers alike to keep it at a reasonable amount, or you'll wake up one day with something that can't release new features, function, scale or be maintained. It is also worth stating that tech debt can have little to no siginifcance to the success of a startup.

wolco2 6y ago
Technical debt starts to matter when the initial project changes focus or patches start mountig. These days rewrites are popular. They make sense in some cases (when the project is smaller or introducing new framework). But in others where the original developer and business people have left and no one knows exactly how things work aside from they need to continue to do the same. In those cases fixing technical debt is extremely important. A startup is more likely to fall into the above category if they ignore their technical debt because rewrites are hard and messy.
Mertax 6y ago
Seems to me that technical debt needs to be dealt with as a function of the revenue the company/product is bringing in. The wisdom comes from timing the investment so it’s not destroying the “mature” product due to entropy or strangling the new product due over engineering. Startups do seem to have bigger issues than technical debt to deal with. Because relatively speaking, there are bigger mountains to climb early in the startup’s development.
kubanczyk 6y ago
It is moreover not entirely unworthy to state that tech debt can have little to no siginifcance to the success of the founder of a startup. /s

spaetzleesser 6y ago

On the other hand a lot of efforts to avoid technical debt end up producing more technical debt because in the end you don't know where things will be going. I think refactoring just needs to be an ongoing effort and should almost never be an explicit task.

mytailorisrich 6y ago

If, for example, there is no requirement to support multiple currencies then there is no need to spend time on designing for multiple currencies "just in case". This is not choosing an easy solution, this is doing just what needed instead of wasting time and efforts on something that may never actually be needed. Now, the design should be sound and follow good practices. This is how to limit the rework needed when new features are added because it is impossible to design to cover all possible future features: Do the minimum but do it cleanly.

anm89 6y ago

I don't buy this concept. It's like saying "Financial Debt: Why it will ruin your company" Yeah it can if you abuse it. It can also be incredibly helpful.

solumos 6y ago
Absolutely. There are payday loans (poorly developed systems) that are clearly always a bad idea, and then there are mortgages (well-architected w/ focus on minimum viability) that get you much farther in terms of realized value than you could by saving up for a house (over-engineering).

SkyPuncher 6y ago

I'm being a bit blunt here. It's easy to say Technical Debt will ruin your software when you pick a contrived thing and label it as Technical Debt. > John knew his code had a few bugs. But nearing the deadline, another project appeared and it took a lot of John’s time, so he couldn’t go back and fix the problems. This is a problem, but this is not inherently technical debt. That's just delivering a bad/incomplete feature (Not necessarily John's fault if he's been asked to make changes). Code with Technical debt works or mostly works, but relies on non-maintainable or less ideal than patterns. Simplified example. Adding a "Cancel" Button to a form. This button involves adding a new "secondary" class style to the button. * Technical Debt - Button is in place. Works correctly. Instead of a <Button> component and tweaking it to handle the new "secondary" class. John simply copies and pastes the <Button> code directly into the implementation. * Bug/Bad Feature - John references the button correctly, but fails to handle certain state resets properly when the form is cancelled. ----- The prior is technical debt because it works correctly, but doesn't follow a good pattern or does something unexpected (refactoring that button will be much, much harder). The latter is likely just bad code. The case where the latter is not bad code is if the company has made an intentional decision to not handle cancel edge cases. Even here, I would argue that is product debt - not technical debt. ---- Every software product in the world has debt. Just like every software product in the world has bugs. You need to account for your debt as you grow. Otherwise it will eat you.

mikepurvis 6y ago
There's a grey area though, where you properly define a new style (yay) at the time the first Cancel button is created, but then down the road you find yourself with a whole bunch of new styles for things, and it turns out over time that the styles are maybe repetitious or subtly inconsistent or whatever. The debt has become the reality that the initial abstraction ("all our buttons are the same") hasn't kept pace with the needs of the product as it has iterated forward. Paying down the debt is creating new abstractions and updating all the buttons to be using them. The worst case scenario is probably partial paydowns, where the abstractions get changed but some of the non-aligned stuff remains and so that you end up with a jumble. Especially combined with inadequate documentation (or a culture of inadequate documentation, where people don't even look because they don't expect it to be there), the old practices can end up being cargo culted forward even when someone attempted to create a better way.

lxe 6y ago

Just like any debt, technical debt is not "always bad". The point of incurring debt is to make a "large payment" (deliver software) quickly and immediately, in exchange for paying interest over time. If you can deliver a working prototype, scale, get funded, and grow your business quickly in exchange of technical debt, that's not really a bad deal.

6510 6y ago

In the early days of computers the first working version was always so slow rewriting it a few times was an obvious step. You would end up improving a lot of things not necessarily related to speed. I still often crank out a really shitty version that works just to get to the points that require some deep thought. You can get a lot of work done if nothing really matters. The first rewrite is helped a lot by having done things before. The second full rewrite sadly never happens anymore. Just incremental changes.

VikingCoder 6y ago

Bad tech debt will ruin your software, but good tech debt is a smart investment in your business. It takes a good team working together to balance their "tech debt budget" against the other revenue needs of the company. If I've run on Version X of some DB software for a while, and tomorrow Version X + 1 is released, yes, I should recognize that staying on Version X is tech debt. But that may absolutely be the right thing to do for now.

CoffeeDregs 6y ago

Technical debt is like credit card debt: it's high interest; it's not a huge issue if you use it wisely; and you have to track its usage and level against your total code/assets. Like credit card debt, too many people turn around and they've got $20k of credit card debt or 20k LOC of tech debt. I don't have too much of a problem with tech debt as long as: the benefit is clear; the debt is well understood; the payoff date/cost is planned. Just last night I was talking with a developer who works for me: "This way will require 5 queries instead of 1. Can you help me figure out this whacky ORM API to do it in 1?"; "Just do it as 5 right now and, as we learn more about the ORM API, we'll fix it later..." Tech debt: we get the product done faster; we've got a 1-5 line change to make (when we know how to make it); and we'll do so in a few months.

pak9rabid 6y ago
>and we'll do so in a few months. Ah, famous last words that I myself have also spoken from time to time.
- nullsense 6y ago
  Yup. Mentally I pipe everything any devs, including myself, say through a sed command like this: s/for now/forever/g
heelix 6y ago
I love this analogy. Dealing with a minor set of updates ... that now need to be done in 60+ all slightly different codebases for this weekend. I'm using it in our next chat with the business side.
iainctduncan 6y ago
Yes, this is totally on the money. This is exactly what we want to see when assessing tech debt on an acquisition assessment (I do tech diligence for acquisitions). If you do it for good reasons, and you track it, and you proactively allocate resources on an ongoing basis or make tech debt remediation a first class road map item, it's not a problem, it might even be a good thing. If you wracked it up playing fast and loose and being all "go fast and break things", it could cost you the deal, or millions of dollars off the deal price.

kylegill 6y ago

I like to think of Technical Debt like an accountant or CFO would think about Financial Debt. It provides leverage to incur debt at early stages, incur too much and it can really come back to bite, but a startup that incurs no debt will struggle to grow.

chairleader 6y ago

Interesting. I would say that John didn't build a solution that met all of the use cases that the business needed. * To ensure accuracy of transactions, he should have built reporting to meet the needs of accountants. * To support change, he should have kept his components separate and provided modest testing examples. * To support developers and operations, he should have found and documented the external dependencies along with steps to verify that they are in place. Whether product managers didn't uncover these requirements or the business didn't prioritize them, these aspects of the definition of "done" have more to do with thee environment the engineer is working in and less to do with his or her work.

papito 6y ago

There is bad technical debt and there is acceptable technical debt. The mark of a good engineer is knowing where to cut the corners - which you will always have to do. Hardcoding something in a file rather than pulling it from a config or a database has a pretty good ROI in terms of time saved, and it's not that hard to change later, but tying yourself to, say, a kind of storage that you know is not going to work long-term, that will cost you later. Also, sometimes doing MORE results in more technical debt. If you are going to spend your time building a Kubernetes cluster because "your home page has to be webscale", you are an idiot.

kgilpin 6y ago

Discussion of technical debt always seems to devolve into an augment about what technical debt actually is. Are there specific patterns of code behavior, metrics which can be derived from analyzing code, quality scores that are non-controversial, which can be used to define this problem? Things that can be measured and managed in a canonical way? How can some knowledge of experienced CTOs be distilled so that we can start to automate some of this wisdom?

bananaface 6y ago
I would say: technical debt is anything that makes the system more expensive to maintain (and grow) over time, and becomes more expensive to fix the longer you leave it. If it's just a bad or incomplete aspect of the system, that's not sufficient. It has to become more expensive over time. So e.g. lack of functionality isn't tech debt, but a bad abstraction is usually tech debt.

tabtab 6y ago

There is a balancing point between under-analysis and over-analysis. It's hard to know the true requirements until the system is actually in production. You can't realistically pre-learn many domain lessons: you just have to dive in and see what floats by setting sail. Finding the best balancing point is hard to turn into a sure-fire formula. I use experience (age) to make a best guess based on on past successes and failures and project types. One tip is to collect and keep a list of questions and suggestions, and make sure they are sufficiently explored. You can't answer questions that have not been asked, but AT LEAST answer those that are asked. Make sure staff is not afraid to ask questions or make suggestions.

flavius29663 6y ago
You have to release the software, with hardcoded inputs, limitations and bugs. That is fine. Having a clean code helps you then quickly polishing it and evolving it based on the customer needs. I prefer that to an over designed system, that is 80% clean and 20% crap, because that is hard to change as time goes by, and that 80% will stay the same, but will become 50% and then 10% of the total codebase.
- tabtab 6y ago
  Nobody agrees on what "clean code" is. I agree there are rules of thumb most will accept, such as try to be modular (group related things together), manage constants in a table or central class instead of hard-wire them, factor heavily repeated patterns into subroutines/methods/classes, comment at least the "big picture" of sections, and the oddities.

skybrian 6y ago

This would be more interesting if it told us more about what actually happened with the Tower of Pisa.

pryelluw 6y ago

I started to use technical liability and technical asset in lieu of technical debt. Easier to explain and provides more insight into good engineering choices.

nullsense 6y ago
I like the metaphor technical tax, as it's the cruft that usually permanently sucks up x% of your development capacity. If it ratchets up permanently, after some time you're at a complete standstill.

mgamache 6y ago

Technical Debt is not a thing when you are coding a new feature. It’s like a stock future. It might be debt, but it might be something no one uses or gets dropped (or rolled into another feature). There’s a cost to speed that has to be considered. Maybe it’s debt, maybe you save the time and spend it on other more valuable tasks.

chandmk 6y ago

One questions I ask myself to bring clarity is, If I am the one paying bills, would I really pay another developer for this refactoring? Yes: Technical debt it is. No: just busy work.

beiller 6y ago

Does anyone have any examples of companies that died because of too much technical debt? For me its kind of one of those things I acknowledge exists but I try to avoid any projects where their goal is purely "decrease technical debt" or even when that goal is on the periphery. And I see that kind of thing way more frequently than you might think!

Jtsummers 6y ago
Not a company, but a project. It has not died yet, it is instead being rewritten while the old one is on life support. The technical debt accrued due to: 1. Poor code practices (C++, poor use or understanding of pointers and threads created most of the actual errors in the program that make it unstable) 2. Excessive copy/paste (so bad decisions propagated quickly) 3. Poor architecture (didn't scale, performance is technically fine but development costs exploded as new capabilities were added) 4. Poor testing (almost entirely manual, as the system grew this grew with it to the point of creating major delays in releases) They're rewriting it now keeping these lessons in mind. They're surviving because they're part of a larger org that can afford to keep them around for the rewrite, but essentially this now 10-12 year old system is dead. The other reason they're surviving is they happen to have only one competitor, whose product costs 10x as much per seat. So their customers want them to survive if they can hit the quality improvements in the rewrite, failing that they'll be disbanded.
deleted 6y ago
[deleted]

hardwaregeek 6y ago

I've become skeptical of people talking about technical debt and clean code and all the standard Fowler/Uncle Bob/PragProg-isms. Not because they're wrong. If anything they're all right, but in a rather vacuous, well-yeah way. Yes technical debt is bad. Yes we should start with a design. Yes we should do refactoring. But using the analogy of the author, that's like telling someone who's overweight and eating a lot of junk food that they should "eat healthier and exercise". Well yeah. They probably knew that already. And so many people try to make it a dichotomy. Like that diagram of a project with a design versus without. That's not a fair comparison. What does a design even mean? Wireframes? A written document of features? How do we change this design? What's the way in which we get feedback? And what sort of projects are we talking here? A programming language is very different from a website. And what even counts as no design? Some other notes: - I'm not sure the author correctly used the Pareto principle. It's not just a generic "split things into 80/20" but a specific observation on how 20% of the causes result in 80% of the effects. - The post could have used a quick proofread. There's quite a few spelling mistakes and poorly phrased sentences. I totally get if the author is not a native speaker, but they could easily enlist one to help (if the author wishes, I'd be happy to proofread—contact me). - I get the whole "make this post fun with cats!" but honestly I'd prefer a straightforward example with no funny images. Maybe that's just my grumpiness.

SkyPuncher 6y ago
> Yes technical debt is bad. Technical debt is like any debt. It's bad if you come due on it and don't have the resources to pay it off. Unlike cash debts, technical debt rarely comes due in a tangible fashion. If getting to my next round vs. failing means leveraging technical debt, I'm going to do that by all means. It's not necessarily easier to fix tech debt at scale, but having more resources means it's less impactful on bandwidth.
- nilkn 6y ago
  This is my preferred way of thinking about it too. I wouldn't say debt in general is universally bad, and so I wouldn't say the same thing about technical debt either. Technical debt can save a company by pushing something forward and launching a product sooner than a competitor. It can save a big customer by fixing a bug for them quickly that if not fixed immediately would have caused them to cancel a multimillion dollar contract. It can also eat away at a company if you let it accrue for decades and never pay it down.

psysharp 6y ago

I see an issue in the web industry that there is sometimes an economical incentive to maintain a solution with technical debt. Just ponder the idea that you hire a bunch of contractors to build you a house, and then you keep them on payroll to come back and fix every broken pipe that they installed to begin with. Even if they feel honor for their work the'll soon drift in to ugly insustainable work due to the nature of their incentives. We might need a proper system to hold engineers responsible insted of hiding behind a company, and in the long run be a solution that provides _space_ for engineers, plausibly.

gregjor 6y ago

Much of the discussion and worry about technical debt stems from a few fallacies programmers seem to fall into: 1. Some objectively "right" or "best" way to write software exists. We refer to "patterns" and "best practices" as if those had the force of science behind them, even though at the same time we can't, as a profession, agree on what we mean. 2. Code we (or someone else down the road) has to maintain wasn't written correctly or perfectly in the first place. Programmers tend to hate maintenance work. 3. We imagine that we could write the perfect program if only our managers and customers didn't impose time and budget constraints, or interfere with their stupid product and marketing directives. 4. Failing to write perfect code that lasts forever indicates a failure on the part of the programmer or the team. 5. Perfectionism (a symptom of obsessive-compulsive behavior) and the increasing worry among programmers about how others perceive and critique their code. Writing perfect code that requires minimal maintenance in the future would require knowing that future, and all of the changes to requirements and constraints that will happen during the lifetime of the code. We can only work with the requirements we know, and those we can reasonably anticipate. Trying to code for requirements we don't have is usually called "overengineering," which means something else in other engineering contexts (as a few other commenters pointed out). I have worked in software development for 40 years so I know that almost no one likes doing maintenance work, especially on someone else's code, and especially with languages and tools no longer in fashion. Maintenance programming is often given to new hires and junior programmers, while the senior developers get to write new code and play with the latest toys. This class division among programmers, often expressed in terms of what makes a programmer junior or senior, gets exacerbated by the personal quality of programming. Programming is a craft, not a science, not even engineering, but we forget that and try to express aesthetic preferences in terms of objective quality, even when we don't have agreed-upon ways to measure objective quality of code. Most software has a short lifespan, which means the "technical debt" will disappear when the code gets rewritten or replaced by a SAAS product or the requirements change. Bridges are expected to stand for decades or even centuries. Jumbo jets have lifespans measured in decades. Very few software projects will stay in use that long. I routinely work on web sites that will stay online for less than a year, because they support short-term marketing goals. American companies have an average lifespan of 18 years, and startups are more likely to go out of business (or get acquired) than to stay in business for even a few years, so focusing on building the equivalent of the Great Pyramid in code at a startup or small company in order to avoid "technical debt" is almost always wasted effort. Businesses factor maintenance into the lifetime cost of software just like they factor maintenance (and depreciation) into the cost of buying a fleet of trucks or a truckload of copying machines. It's the programmers who impose unrealistic goals of no/low maintenance and frame that inevitable maintenance work as a failure of the original design or implementation, i.e. technical debt. We should try to do our best work, to make code that works (i.e. meets requirements and doesn't suffer from preventable bugs), and we should try to anticipate likely changes and make those easy for the next programmer. We should stop imagining a perfectly right way to write code, and stop thinking that maintenance work is beneath us, or a sign that the last team didn't know what they were doing. I think programmers would enhance their value and learn a more realistic (and maybe humble) approach to their craft if they didn't think of programming as an isolated activity disconnected from the business and customers/users their code is meant to serve. James Joyce wrote “What makes most people’s lives unhappy is some disappointed romanticism, some unrealizable or misconceived ideal. In fact you may say that idealism is the ruin of man, and if we lived down to fact, as primitive man had to do, we would be better off....” Joyce wasn't talking about programming, but I try to keep that in mind when balancing technical decisions against the larger set of business and customer concerns.

mkl95 6y ago

There are many dimensions to technical debt, but the biggest one 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 manager or by quitting their job.

projektfu 6y ago

Seems like if you want to make that statement (it'll ruin your software) you need more than a hypothetical example. There are some good ones in memory. 1. Netscape Navigator - was such "spaghetti" that they had trouble re-architecting it to allow it to keep up with evolving web standards, and then put everything into Navigator 6.0 which ended up running like a snail. (Second system effect). I'll note that according to jwz, it was written by people working lots of all-nighters. 2. Microsoft Word for Windows. Apparently had a ponzi-like accumulation of technical debt as they kept adding features to the release and writing code that looked technically correct but was known to be flawed, relying on testers to find the bugs they had known they wrote. Took version 2 for the bugs to get ironed out to a usable state. I've tried coding with some open source programs that are mostly being used for a company's internal process that are basically piles of technical debt, but it'd be rude to mention. I'm sure there are other great ones, but now that so much software is SaaS, we're probably not going to hear about it, because the release dates aren't as obvious. To me, eBay appears to be one, as they are trying to remake their web application to be more modern but it has tons of warts all over it.

Justsignedup 6y ago

One thing I'd like to point out: The tower in Piza was leaning, and gonna collapse. Then an architect devised a way to fix it. They of course said "hell no" because literally the only thing going on in Piza is the tower. To fix/destroy it would destroy the entire economy in Piza. So instead they chose to lift/stabilize it.

slumdev 6y ago

The problem with "technical debt" as a meme is twofold: It's a lousy analogy, and people tend to label absolute garbage as "tech debt". The garbage is not a tool to enable quick growth. It's not a shortcut. It's just garbage. "Technical debt" conversations usually go something like this: Me: "Could we spend a few hours getting a handle on what the data model should look like? Maybe rough out a crude ER diagram?" PHB: "Oh slumdev, you're such a Boy Scout. Just blam it into a document store. If something changes, we'll just be Agile about it. Technical debt is a tool!"

Aeolun 6y ago
Cue 300% increase in development time.
- Viliam1234 6y ago
  Overtime and on-call duty come to save the day.
  - Aeolun 6y ago
    Ah, yes, if we just work 160 hours per week we can just about get it done at the originally estimated time. I guess that means you can take an hour long nap every day to recover before your next shift.

chmod600 6y ago

I don't think debt is really a great analogy. Lot's of people are comfortable with debt, if nothing else. I think it's more like a rushed major remodel of a house. It's kinda bad, but there's really just no practical way to fix it without a teardown.

nullsense 6y ago
Yup. It's actually technical tax.

karmakaze 6y ago

> Let’s dive deeper into the problems of John’s code: - Payments couldn’t be processed in different currencies - If the delivery system is offline, the code wouldn’t work - Users with deactivated accounts could still access the system - No automated testing > And this, my friends, is what we know as Technical Debt. Why? Ah no, this is what is known as a broken software development process.

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. 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.

dredmorbius 6y ago
Cunningham makes a convincing case for the teerm: https://youtube.com/watch?v=pqeJFYwnkjE https://youtube.com/watch?v=pqeJFYwnkjE (4m44s)
- lowbloodsugar 6y ago
  He made a convincing case for why its like "debt", but he fails to make a convincing case for its use, or any case at all that using the term has a positive impact on a team's success. He even calls out that some teams think they don't have to pay back the debt. I think that is the norm, and that's the problem of debt. When financial people use debt, that debt comes with structure and consequence: it might be monthly payments or it might be due sometime in the future. Offer such people a "debt" that has nobody enforcing it, nobody quantifying it and of course it wont be paid back. Agile engineers making scary "booga booga" noises about "we need to refactor" just don't carry the same weight as not being able to make payroll because your note is due. And yet that seems surprising to engineers.

jpswade 6y ago

I think this assumes you want to write perfect software, when sometimes it just needs to be good enough.

intricatedetail 6y ago

I find it fascinating that buggy product is considered as delivered. That is the root of the problem.

BobBagwill 6y ago

There are an uncountably large number of pathways one's efforts toward a goal can take. Given that the future is unknowable, any decision one makes can turn out to be an inconvenient (not necessarily wrong) decision. That is "technical debt". It is unavoidable. If you are ignorant of the possible consequences of decision, or choose to ignore or hide them, that's something else.

RandyRanderson 6y ago

IMO, a more pernicious form the tech debt starts with one system. A second person comes along and builds their own system/software b/c of some real or perceived issue with existing software (for example someone thinks something is poorly designed or not the right(tm) technology, etc). This second system then forces integration, APIs, TCP connections between apps. No big deal, right? But the next person comes along and says "I don't like those systems - I want to put tech3 on my resume (a little resume oriented architecture, anyone?) and they build a 3rd system. Now it's really hard to develop features across those apps. One has to be an expert in all those techs. Integration becomes 80% of the work. Now ppl have to create new or buy software just to get anything done. And so it goes. There's a name for this, used a lot on this site.

drbojingle 6y ago

You know what ruins software? Refactoring old stuff you don't like so the code base is "nice", which incidentally introduces 100 bugs that didn't need to exist, pushes deadlines back cause someone has to fix those bugs, and loses customer confidence to the point that investors and customers don't care anymore and then you have no one to build for (but at least your code base is nice and scale-able, to bad 10 x 0 customers is still 0). I've seen more issues because of nonsense like that, or people insisting that code should be DRY and making ridiculous mental contortions in the name of a three letter acronym, or personal taste (the amount of fashion in software development is insane) but I've yet to see a project truly fail because someone cobbled something together quickly, and introduced tech debt. So far anyways.

nullsense 6y ago
Part of a codebase I work on suffers from a quality hotspot where half of it got rewritten so it was "nice" and the other half was so hard to reason about it stopped them dead in their tracks and it has persisted in this Frankenstein state for a reasonably long time. On a project with an external deadline this year I had to make some modifications for compliance reasons. It was very painful. The parts that are rewritten are conceptually a lot simpler. They fit in my head. The parts that didn't get rewritten have incredibly high cyclomatic complexity and really don't fit in my head. I want to refactor it so it's nice. I also don't want to introduce lots of bugs nor push out deadlines. A decision was made upfront that we would try to extract this component out of the main system, so it could be independently modified and deployed, as the capability to do so would actually provide decent business value. Sadly this particular decision didn't turn out well, and really, really pushed the deadline. Ultimately we spent about 70% of the engineering effort on the project trying to extract some functionality. I'd say about 10% of is actually extracted. So now it's even more of a Frankenstein split across 2 codebases now. The project is coming to a close, and we will have a clean up session early next year. Our next project is related to this particular component also, so there is scope for us to be making changes to it. The goal is to make this component more stable for customers, and safer to deploy. I think a big bang rewrite is 80% likely to fail. I strongly suspect it's actually worth succeeding at though. I'm trying to chart a path through to a successful reworking of this critical subsystem. The first failure was quite humbling, but not unexpected. Probably the best move I made on this project was getting good logging in place so I can tell exactly what it does, and made it a lot easier to reason about whether our attempted extraction does the same thing. Also I've managed to collapse some of the cyclomatic complexity, so it's easier to mentally keep track of as you're trying to read the code. It's still very, very hard to modify the functionality of the old stuff. My current line of thinking on the best way forward is to abandon the attempted extraction, and repatriate that functionality to the main codebase. Then use characterization/approval tests and finish the original rewrite. I'd be happy to do it piecemeal too, even one ticket a sprint spread out over the course of the year, so long as we actually complete it. In addition I'm planning to try a a tiny, reversible experiment at a different way of extracting it that's much more likely to succeed and deliver the benefits we're looking for while simultaneously charting a way forward on another major piece of tech debt that causes a lot of stability problems. If that experiment succeeds I want to extract all of it that way, and would only attempt to do so once the entire thing was in a reasonable condition first. Getting it all the way to that state would represent a major win in my mind. It's hard when we can't afford to fail at this, and we're not likely to succeed. Really trying my best to find a viable plan. At the same time, if it ain't (that) broke, don't fix it right? But that leaves no road to new capabilities for us as a business. Software is just a hard problem.

phendrenad2 6y ago

I've never seen a project or company killed by tech debt. I've seen projects and companies killed by obsessive-compulsively trying to eliminate it. YMMV

salt-licker 6y ago

This article lacks nuance around the tradeoffs inherent in shipping complex software at maximum velocity. Much more useful is evaluating the long-term impact of specific instances of technical debt, particularly “contagion”: https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxonomy-tech-debt

iainctduncan 6y ago

Assessing tech debt is basically my job these days, as I'm an architecture and infrastructure consultant for technical due diligence on acquisitions, mostly by PE firms. Some fun things you might not know from the field of technical due diligence: - Your startup is much more likely to succeed by being purchased by a private equity fund than anything else these days. Most tech acquisitions are now PE, like over 75% of big ones. (Even up to north of a billion) - The PE fund will send a diligence team. Depending on who they hire, your diligence team could be clueless consultants with checklists, or they could be real hackers who will look at your code, ask all the hard questions, and know a lot about tech debt. They will talk to you for many hours about tech debt. We typically interview for 12 hours and ask for a lot of metrics and docs. We do this for a living, so we're pretty good at sniffing out BS and knowing how to get devs to talk about their software realistically. Most devs are pretty happy to talk shop once they know we are actually developers who have been through the same process ourselves. Sometimes I feel like it's more like Developer Therapy. :-) - If you have bad tech debt, it won't necessarily sink a deal. Deals usually go through or not on other reasons, like business model revenue numbers - stuff that can't be fixed with the application of cash. However, we make a table for them of estimated cost to mitigate debt, and that can be serious cash. (i.e. X extra senior devs and QA for Y months/years) - This cash will come off the price. Or as Amazon apparently puts it... "a haircut". A haircut can easily run over a million on even a small company. So the money saved on devs for the years of accruing debt just comes off the acquisition price, but with a terrible interest rate. Also of interest: we don't actually say it's always bad. We differentiate between intentional and unintentional debt. If you accrued debt to get to market quickly and are then doubling back to attend to it reasonably, that can be a very smart decision and may actually reflect well on the assessment. On the other, debt accrued because the founders only hired interns and new grads and let them run the asylum for years does not. If I were to encapsulate in one sentence what I've learnt about tech debt in the last two years and 50 odd companies examined it would be this: nobody saves money by trying to hire mostly junior developers. Nope nope nope nope nope. If you are running a start up, you need at least a couple of six figure salary, 5+ years experience devs, and a CTO or lead architect with like 10+ years or who really, really knows their stuff. Do not cheap out on this! At a guess, I'd say it's the most obvious differentiator between the hits and the really big haircuts. That said, I only look at companies who have gotten pretty far, so the main differentiator is likely different at early VC stage. We're basically doing the first exit, and if we're talking to you, you have a successful business that some professional big time investors want in on. Hope that's of interest to some folks! :-)

voodootrucker 6y ago

What a garbage article with too many cats.

nojvek 6y ago

Technical Debt only really counts if you have to pay interest on it. Many times I see new engineers wanting to re-write old working code in their new favorite language. My litmus test for technical debt is things we should have done a while ago, but since we didn’t it’s hurting us. Continuing on same path will hurt even more. Better to fix the pain and then move on. Working code that does what it needs and doesn’t require much maintenance is great code. Old != technical debt.

yenwel 6y ago

I've worked on two seperate old code bases with pms who read the lean startup and they believed that technical debt does not exist. Seriously aggravating the situation thus. They did not seem to understand that the main thesis for that book is assuming that you have one in a million change of becoming a unicorn or selling the company to another party and cashing out.

jesssinnss 6y ago

Technical debt is not a thing. It’s made up by people who want things done in a different way than they currently are. All currently good design recommendations will become wrong ones in the future. Today’s best practice is tomorrow’s technical debt. There is just code that works and makes the company money, and code that doesn’t work. Code that is readable and code that is not readable. Starting out with “the right design” will become the wrong design when the market changes and the specs change under your feet. Moving fast and making software that meets market needs requires going back and finding parts that need to be consolidated. It’s just how building software in the non-trilllion-dollar-company-or-in-academy world works.