7 ms·

My only bone of contention is that taking on debt is usually a conscious choice. Technical debt to my mind is the price of making a pragmatic decision, it’s the

by ljm 7y ago

My only bone of contention is that taking on debt is usually a conscious choice. Technical debt to my mind is the price of making a pragmatic decision, it’s the trade-off that lingers. Making poor architectural decisions or writing poor quality code isn’t tech debt. They are just institutionalised consequences. The way the world now works. Legacy code isn’t tech debt either: it was right for the time. What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future hiring decisions, particularly when those are made independently of the team. If you want to establish tech debt you have to define the schedule to pay it off and there should be some record of that work somewhere, with accountability attached. It is not merely the accumulation of things you don’t like the look of or find hard to work with. Similarly, I think MVP is a conscious choice to incur product debt because it is far too risky and irresponsible to go all-in with your perfect vision right off the bat. You want your initial buy in and a chance to bail out or pivot before all is lost. Edit: as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities. If they think COBOL is no longer fit for purpose, it’s not debt, it’s time to reinvest.

ses1984 7y ago
I don't see the distinction between knowledge and technical debt unless you count knowledge debt as a subset of technical debt. You make a choice to accumulate knowledge debt by not writing docs, not cross training team mates, etc.
- ljm 7y ago
  I count knowledge debt as a superset. You can’t determine the state of a codebase without first knowing the decisions that were made when it was being written. This, and I will accept being wrong, is why I think we see code we didn’t write and immediately see how we would do it better. What we’re doing is sending ourselves back in time and replacing their shoes with our own. They didn’t know what you know and you have no idea what they knew. A potentially effective approach is to introduce an immutable decision log. We have these people in many other fields - they record the decisions made and they become part of the overall reasoning. I reckon anyone in a position of power should have an independent decision log. Tech architects, CTOs...
allenu 7y ago
Totally agree. In my opinion, with this type of MVP strategy, work done should always be in the service of something else. Initially, an MVP is created to test out ideas and also to learn what structurally it takes to build your product. After the MVP, you may wish to add more features or support more users, it is at that point that you can assess what is debt and what is not. It's not a matter of "cruftiness" but a matter of what's holding you back from adding additional features or supporting a larger number of users. If we frame all work as doing something that will deliver some sort of value (be it customer value or unlock the potential to add more features to add customer value), then it becomes a more constructive conversation about work that needs to be done, debt or otherwise. I'm not a fan of just looking at whether code is crufty or not to determine if it's "technical debt". If you look at code long enough, you'll find something you don't like and want to rewrite, but it has to be in the service of some other goal or else you'll just become an architecture astronaut building wonderful things that don't provide value.
stcredzero 7y ago
Legacy code isn’t tech debt either: it was right for the time... Edit: as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities. If they think COBOL is no longer fit for purpose, it’s not debt, it’s time to reinvest. Should there be an analogy for depreciation? Some of the "best practices" in my current C++ shop are in direct contradiction to the Law of Demeter and related philosophical stances in Object Oriented programming (particularly ones espoused by Martin Fowler) despite the fact that my current shop advocates for OO. Neither the old position or the my current shop's position is so bad that it's not viable, though some hotheads in the field act as though this could be the case. A lot of the churn seems to be arbitrary and driven more by fashion than solid first principles. (Which would include cost-benefit analysis, for which there is often insufficient data, and for which no one wants to pay the cost to gather the data.)
bryanrasmussen 7y ago
>writing poor quality code isn’t tech debt. sure it is, in the same way that taking one of those payday loans to cover a coke habit is still real debt, it's just real bad debt.
- ljm 7y ago
  I don’t believe we can equate jonesing for a fresh hit to writing well intentioned but ultimately difficult code or the product of inexperience. Besides which, it trivialises the seriousness and the tragedy of addiction. If you think your tech debt is similar to that you are well equipped to quit your job and work elsewhere. An addict does not have such an easy choice, they can’t leave their addiction to someone else and move on. You choose to take the payday loan or hit up a shark, addiction or no. The point where I concur is when you gamble the short term against the future despite all evidence that you will benefit from spending time to save time.
  - UnFleshedOne 7y ago
    The victim in that metaphor is not an individual coder who can go work elsewhere, it is the org who takes on technical debt and sometimes can't function at all without the code in question.
  - therealjumbo 7y ago
    >I don’t believe we can equate jonesing for a fresh hit to writing well intentioned but ultimately difficult code or the product of inexperience. Agreed. The addict might recover. Organizations with poor culture are doomed.
  - bryanrasmussen 7y ago
    all analogies and metaphors are in some ways inexact - indeed the whole concept of technical debt as a thing correlating to real debt is fraught with edge cases that don't exactly line up. Nonetheless if the metaphor has some utility then individual expressions of it such as mine will often have some utility - hence your concurring on a single point while finding other implications problematic.
  - 7y ago
danielecook 7y ago
> Legacy code isn’t tech debt either: it was right for the time. Doesn’t this assume that code as written was of the highest quality? Under tight deadlines or misaligned priorities code quality suffers. Even if it works or “is right” doesn’t mean it wasn’t done to a standard that maximizes productivity.
- ljm 7y ago
  I don’t believe so, I’m just saying it wasn’t seen as a debt at the time. It might well have been the best they could do given the constraints. If they consciously chose to sacrifice on it, that’s the debt.
delusional 7y ago
Where I work, we actually do use technical debt to cover unknown defects as well. So if a person writes bad code, or if we have some legacy code that has suffered from rot, we'd call that technical debt. I think there's a lot of value to be found in separating the known debt from the unknown debt though, and giving it a name. I might have to start doing it. So thanks for making me think about it.
coding123 7y ago
I think of all the code written as technical debt. As soon as you write it, it becomes a burden - just like regular financial debt. However instead of thinking of code like a credit card loan that will take a few years to pay off, think of it like a mortgage that you have for 30 years. At the 30 year mark, you will generally have retired the code, hopefully. If you're not so lucky, you should expect to see balloon payments coming shortly. I know this isn't a perfect metaphor because honestly "technical debt" applies to all code, not just slightly bad code. That's very different from a loan.
- Jedd 7y ago
  I suggest that all code is a liability, rather than a debt per se. This assumes all things can be usefully viewed through the prism and language of economics (though my gut feel is few things can or should be).
  - aaronchall 7y ago
    Liabilities are debts. > liability: a thing for which someone is responsible, especially a debt or financial obligation. According to the balance sheet equation, > Assets = Liabilities + Owners Equity Certainly all code is a liability - it must be at least understood and maintained from time to time (80% of lifetime cost is in the maintenance). And while an accountant might also mark it an asset - not all code is an asset - and we recognize that fact when we delete for badness or disuse - or rewrite it to make extending and maintaining it easier.
    - Jedd 7y ago
      As intimated, I'm not sure that the fuzzy language and world of economics is the best way to view such things, however ... I'd accept that debts are a subset of liabilities, but not that 'liabilities are debts'. A debt implies an externality, while a liability implies some generic exposure -- it's that which I focus on when considering (all) code as a risk to an organisation. I suspect, however, that we agree on the fundamentals. There's some cost and risk to developing and trying to maintain any code base, and accepting that can usefully inform development and operations work better than thinking of code as a (near-)risk-free asset.
azernik 7y ago
It was right for the time, and required maintenance and updating; I consider skipping said maintenance to be a debt of the time it would take to do that maintenance, with the interest being the time spent working around it as you work on other things. In a lot of cases, the interest rate is pretty low, and is worth it.
eweise 7y ago
"Legacy code isn’t tech debt either: it was right for the time." really? Isn't that what technical debt is, solution that no longer fits the current problem?
- spydum 7y ago
  No, solution still fits the problem space but requires more than investment to improve efficiency/quality/etc of future management of the technology. The cobol example is great - it is code still solving the problem but is no longer efficient or productive to find and pay cobol programmers.
  - eweise 7y ago
    If the code still fit the problem then you wouldn't need to pay a cobol programmer. If its hard to change the code because its too expensive to change, then you have tech debt.
    - adamdonahue 7y ago
      But it's only debt if business decisions mean you must change it. I've seen far too many programmers crawl through legacy code that need not be replaced (it does its job) merely because it's using an outdated technology. But if there's no business justification for that, I'd argue it's not debt at all. There is absolutely nothing wrong with some ugly COBOL code doing its job with no current need for modification. That's not debt. Debt is something you have to pay back.
dragonwriter 7y ago
> Legacy code isn’t tech debt either “Legacy code” is usually a label applied exactly to identify that code which has been determined to represent technical debt.
- tomrod 7y ago
  Agreed. Technical debt is the accrued cost of maintenance -- underpaying maintenance is a typical recipe for poor outcomes.
- charrondev 7y ago
  I heard a recent conference talk where it was referenced as “Revenue Generating Code”, rather than “Legacy Code”. I found it be a pretty accurate summation that gives some perspective from the other side.
  - dragonwriter 7y ago
    > I heard a recent conference talk where it was referenced as “Revenue Generating Code”, rather than “Legacy Code”. The two categories overlap, but not all code generating revenue fits in the traditional scope of “Legacy Code” and not all “Legacy Code” is generating revenue. > I found it be a pretty accurate summation that gives some perspective from the other side. What “other side” are you referring to?
    - charrondev 7y ago
      It’s not a perfect overlap. I agree with you there. My personal experience has led me to believe that “Revenue Generating Code” is the most common variety of technical debt. Technical debt that does not generate revenue in any way is often far easier to replace/refactor. I look at legacy code like this: - Could we remove this from the product? - Could we replace this part of the product with a totally new system? - Are we OK with potentially introducing subtle bugs in this code as we work through refactoring it. If the answer to the above questions are “No”, it’s likely revenue generating code (or part of some compliance process). In this case the “other side” is non-technical stakeholders who don’t inherently understand the importance of resolving technical debt.
philwelch 7y ago
If you buy thousands of dollars of unnecessary crap with your credit card, you’re still in “debt”, so the analogy still holds.
romwell 7y ago
>What you have instead is knowledge debt as engineers turn over ... This isn’t tech debt You know, if there only were a way to pass knowledge from one person to another aside from directly talking to that person. Perhaps if we had means of preserving knowledge, and even making it a part of the job description... But alas. Joking aside, not writing technical documentation and product design docs is very much technical debt. A lot of information that is lost with turnover is information that could have been written down and passed on. Documentation is not jut code comments. It is: -A solid bug tracking system, with clean and reproducible bug descriptions -A version control history, where every change has a why in addition to a brief how, and which links with the bug tracker -Well-written tests, which not only verify how a system works, but showcase how to use the APIs. -Documentation for tests explaining why this input was chosen, what kind of output is expected, and why it was written that way -High level comments in code (especially libraries) explaining how the API should be used -High level documentation explaining the structure of the code that is checked in, and lives with the code. The documentation can be in Markdown or a plaintext README, but should be there -A "code map" telling you what the code in various directories does, and where to look for things. -And, most importantly, a lot of design docs - for every feature and algorithm. "We are solving this problem. Here are the alternatives considered. Here is what we are going to do and why. Here is how we'll implement this. We used ideas from this, this, and this paper". Yes, all of that is needed. The price you pay is engineering time. But if you take on the debt, your new engineers will have Hours Of Fun[1] trying to figure out, say, whether the imaginary nanometers[2] model parameter increasing as a result of their change is a good or a bad thing. What I am saying is documentation debt is technical debt. Documentation is just as important as the code. And having it does help[3]. You might think that your code doesn't need all of that. And that's fine; but that means you plan on never paying that debt. Maybe you plan for your startup to fail/sell out in a few years. Maybe you plan to leave that job. But anything long term means you have to write things down. And if you haven't been doing so - now is as good time as ever to start. [1]http://wiki.c2.com/?HoursOfFun http://wiki.c2.com/?HoursOfFun [2]True story. There was a good reason for why the distance parameter had complex-valued nanometers as units; it was an elegant way to do improve a model while staying backwards-compatible. It was written down nowhere, and have fun googling "complex nanometers". They only exist in that code, AFAIK.
- 7y ago
martin_ 7y ago
This is great and well articulated! Would you agree legacy code can often turn into tech debt by virtue of being neglected / unmaintained? The debt here could perhaps be measured by operational overhead
JamesBarney 7y ago
> Making poor architectural decisions or writing poor quality code isn’t tech debt I think it is. Technical debt is all about trading current productivity for future productivity. Poor architectural decisions can be caused by several factors. Inexperienced devs, not taking enough time to understand problem, not spending enough time brainstorming the problem. These are all decisions that trade current productivity for future productivity, which is technical debt. Also most technical debt is not accrued consciously. Very few people are doing cost benefit analysis on technical debt. It's usually made intuitively by project and product managers who don't directly interact with the costs of technical debt but directly experience the benefits.
- collyw 7y ago
  > Inexperienced devs, not taking enough time to understand problem, not spending enough time brainstorming the problem Requirements changing is also a big one. 4 years into one project that I had created and maintained a "one to many" relationship changed to a "many to many" in some of the tables central to the system. Something that I had clarified wouldn't when originally designing the system.
- tremon 7y ago
  > Technical debt is all about trading current productivity for future productivity. This is a very succinct and accurate description, and one I haven't come across. Thank you for this phrasing :)
dep_b 7y ago
The goal of an MVP is not to write crappy code to get something quickly out of the door but to not build every feature into all details to get all of the parts together and see how they work first. It's about the code you don't write, not about the quality of what you do write.
SkyBelow 7y ago
>Making poor architectural decisions or writing poor quality code isn’t tech debt. I compare technical debt to debt. You may go in debt because you looked at the housing market and decided that now is likely a good time to buy a house with low interest rates. You take on a large load of debt, but it is done wisely based on currently information. You may go in debt as a business operating on credit to fund an expansion that should pay off quite nicely in a few years time. Maybe it will fail, but it isn't a bad risk based on current knowledge. You may go in debt for an education. Depending upon the degree and extent of debt this could be good or bad. You may go in debt by spending beyond your means on a credit card. This is generally unwise. You may go in debt because of a medical emergency that is entirely beyond your control (especially in some countries, but even some countries with universal healthcare it is possible to need treatment that isn't covered). All of these have something similar when dealing with technical debt. Sometimes it is a wise investment. Sometimes it is a risk that may or may not pay off. Sometimes it is beyond one's control. Sometimes it is poor planning that will be regretted later.
jkoudys 7y ago
Yeah, I see too often devs shrug off their "technical debt" when what they're really describing is simply sloppy work. These economic metaphors always break down when you challenge the idea that devs/dev managers are always acting in the best interest of the product. I've seen teams cheer their "velocity" because they're closing lots of issues, when most of the things they're focused on shouldn't have even been an issue in the first place. For the cases like legacy code and turnover, perhaps "tech depreciation" is the more appropriate economic term. You didn't really borrow against the future to have more today, rather something naturally decreases in value over time.
- olooney 7y ago
  Right. Technical debt should not be understood on its own but as part of a larger "technical balance sheet" metaphor: technical depreciation, technical amortization, and so on.
goto11 7y ago
Technical debt is a great metaphor exactly because it suggest the suboptimal code is due to a deliberate strategic decision. If you just say that some code is bad you will get unproductive reactions like people getting defensive, trying to assign blame etc. Calling it technical debt allow you to call attention to an issue while avoiding blaming anybody.
kalecserk 7y ago
Great comment, if you allow I would summarize by rephrasing one sentence making it shorter: What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future. That is it! Thank you for sharing your thoughts.
dragonwriter 7y ago
> Legacy code isn’t tech debt either: it was right for the time. The time it was written often isn't when the technical debt was incurred, when maintenance to keep it right, technologically, for the changing time was deferred, that's when a decision was made to incur a higher price later to save now: that's when the (technical) debt was incurred. > as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities The existence of technical debt is unrelated to awareness of the deferred costs. “technical debt” isn't a statement about the existing technical staff’s perception of the system.

by ljm 7y ago

ses1984 7y ago

I don't see the distinction between knowledge and technical debt unless you count knowledge debt as a subset of technical debt. You make a choice to accumulate knowledge debt by not writing docs, not cross training team mates, etc.

ljm 7y ago
I count knowledge debt as a superset. You can’t determine the state of a codebase without first knowing the decisions that were made when it was being written. This, and I will accept being wrong, is why I think we see code we didn’t write and immediately see how we would do it better. What we’re doing is sending ourselves back in time and replacing their shoes with our own. They didn’t know what you know and you have no idea what they knew. A potentially effective approach is to introduce an immutable decision log. We have these people in many other fields - they record the decisions made and they become part of the overall reasoning. I reckon anyone in a position of power should have an independent decision log. Tech architects, CTOs...

allenu 7y ago

Totally agree. In my opinion, with this type of MVP strategy, work done should always be in the service of something else. Initially, an MVP is created to test out ideas and also to learn what structurally it takes to build your product. After the MVP, you may wish to add more features or support more users, it is at that point that you can assess what is debt and what is not. It's not a matter of "cruftiness" but a matter of what's holding you back from adding additional features or supporting a larger number of users. If we frame all work as doing something that will deliver some sort of value (be it customer value or unlock the potential to add more features to add customer value), then it becomes a more constructive conversation about work that needs to be done, debt or otherwise. I'm not a fan of just looking at whether code is crufty or not to determine if it's "technical debt". If you look at code long enough, you'll find something you don't like and want to rewrite, but it has to be in the service of some other goal or else you'll just become an architecture astronaut building wonderful things that don't provide value.

stcredzero 7y ago

Legacy code isn’t tech debt either: it was right for the time... Edit: as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities. If they think COBOL is no longer fit for purpose, it’s not debt, it’s time to reinvest. Should there be an analogy for depreciation? Some of the "best practices" in my current C++ shop are in direct contradiction to the Law of Demeter and related philosophical stances in Object Oriented programming (particularly ones espoused by Martin Fowler) despite the fact that my current shop advocates for OO. Neither the old position or the my current shop's position is so bad that it's not viable, though some hotheads in the field act as though this could be the case. A lot of the churn seems to be arbitrary and driven more by fashion than solid first principles. (Which would include cost-benefit analysis, for which there is often insufficient data, and for which no one wants to pay the cost to gather the data.)

bryanrasmussen 7y ago

>writing poor quality code isn’t tech debt. sure it is, in the same way that taking one of those payday loans to cover a coke habit is still real debt, it's just real bad debt.

ljm 7y ago
I don’t believe we can equate jonesing for a fresh hit to writing well intentioned but ultimately difficult code or the product of inexperience. Besides which, it trivialises the seriousness and the tragedy of addiction. If you think your tech debt is similar to that you are well equipped to quit your job and work elsewhere. An addict does not have such an easy choice, they can’t leave their addiction to someone else and move on. You choose to take the payday loan or hit up a shark, addiction or no. The point where I concur is when you gamble the short term against the future despite all evidence that you will benefit from spending time to save time.
- UnFleshedOne 7y ago
  The victim in that metaphor is not an individual coder who can go work elsewhere, it is the org who takes on technical debt and sometimes can't function at all without the code in question.
- therealjumbo 7y ago
  >I don’t believe we can equate jonesing for a fresh hit to writing well intentioned but ultimately difficult code or the product of inexperience. Agreed. The addict might recover. Organizations with poor culture are doomed.
- bryanrasmussen 7y ago
  all analogies and metaphors are in some ways inexact - indeed the whole concept of technical debt as a thing correlating to real debt is fraught with edge cases that don't exactly line up. Nonetheless if the metaphor has some utility then individual expressions of it such as mine will often have some utility - hence your concurring on a single point while finding other implications problematic.
- 7y ago

danielecook 7y ago

> Legacy code isn’t tech debt either: it was right for the time. Doesn’t this assume that code as written was of the highest quality? Under tight deadlines or misaligned priorities code quality suffers. Even if it works or “is right” doesn’t mean it wasn’t done to a standard that maximizes productivity.

ljm 7y ago
I don’t believe so, I’m just saying it wasn’t seen as a debt at the time. It might well have been the best they could do given the constraints. If they consciously chose to sacrifice on it, that’s the debt.

delusional 7y ago

Where I work, we actually do use technical debt to cover unknown defects as well. So if a person writes bad code, or if we have some legacy code that has suffered from rot, we'd call that technical debt. I think there's a lot of value to be found in separating the known debt from the unknown debt though, and giving it a name. I might have to start doing it. So thanks for making me think about it.

coding123 7y ago

I think of all the code written as technical debt. As soon as you write it, it becomes a burden - just like regular financial debt. However instead of thinking of code like a credit card loan that will take a few years to pay off, think of it like a mortgage that you have for 30 years. At the 30 year mark, you will generally have retired the code, hopefully. If you're not so lucky, you should expect to see balloon payments coming shortly. I know this isn't a perfect metaphor because honestly "technical debt" applies to all code, not just slightly bad code. That's very different from a loan.

Jedd 7y ago
I suggest that all code is a liability, rather than a debt per se. This assumes all things can be usefully viewed through the prism and language of economics (though my gut feel is few things can or should be).
- aaronchall 7y ago
  Liabilities are debts. > liability: a thing for which someone is responsible, especially a debt or financial obligation. According to the balance sheet equation, > Assets = Liabilities + Owners Equity Certainly all code is a liability - it must be at least understood and maintained from time to time (80% of lifetime cost is in the maintenance). And while an accountant might also mark it an asset - not all code is an asset - and we recognize that fact when we delete for badness or disuse - or rewrite it to make extending and maintaining it easier.
  - Jedd 7y ago
    As intimated, I'm not sure that the fuzzy language and world of economics is the best way to view such things, however ... I'd accept that debts are a subset of liabilities, but not that 'liabilities are debts'. A debt implies an externality, while a liability implies some generic exposure -- it's that which I focus on when considering (all) code as a risk to an organisation. I suspect, however, that we agree on the fundamentals. There's some cost and risk to developing and trying to maintain any code base, and accepting that can usefully inform development and operations work better than thinking of code as a (near-)risk-free asset.

azernik 7y ago

It was right for the time, and required maintenance and updating; I consider skipping said maintenance to be a debt of the time it would take to do that maintenance, with the interest being the time spent working around it as you work on other things. In a lot of cases, the interest rate is pretty low, and is worth it.

eweise 7y ago

"Legacy code isn’t tech debt either: it was right for the time." really? Isn't that what technical debt is, solution that no longer fits the current problem?

spydum 7y ago
No, solution still fits the problem space but requires more than investment to improve efficiency/quality/etc of future management of the technology. The cobol example is great - it is code still solving the problem but is no longer efficient or productive to find and pay cobol programmers.
- eweise 7y ago
  If the code still fit the problem then you wouldn't need to pay a cobol programmer. If its hard to change the code because its too expensive to change, then you have tech debt.
  - adamdonahue 7y ago
    But it's only debt if business decisions mean you must change it. I've seen far too many programmers crawl through legacy code that need not be replaced (it does its job) merely because it's using an outdated technology. But if there's no business justification for that, I'd argue it's not debt at all. There is absolutely nothing wrong with some ugly COBOL code doing its job with no current need for modification. That's not debt. Debt is something you have to pay back.

dragonwriter 7y ago

> Legacy code isn’t tech debt either “Legacy code” is usually a label applied exactly to identify that code which has been determined to represent technical debt.

tomrod 7y ago
Agreed. Technical debt is the accrued cost of maintenance -- underpaying maintenance is a typical recipe for poor outcomes.
charrondev 7y ago
I heard a recent conference talk where it was referenced as “Revenue Generating Code”, rather than “Legacy Code”. I found it be a pretty accurate summation that gives some perspective from the other side.
- dragonwriter 7y ago
  > I heard a recent conference talk where it was referenced as “Revenue Generating Code”, rather than “Legacy Code”. The two categories overlap, but not all code generating revenue fits in the traditional scope of “Legacy Code” and not all “Legacy Code” is generating revenue. > I found it be a pretty accurate summation that gives some perspective from the other side. What “other side” are you referring to?
  - charrondev 7y ago
    It’s not a perfect overlap. I agree with you there. My personal experience has led me to believe that “Revenue Generating Code” is the most common variety of technical debt. Technical debt that does not generate revenue in any way is often far easier to replace/refactor. I look at legacy code like this: - Could we remove this from the product? - Could we replace this part of the product with a totally new system? - Are we OK with potentially introducing subtle bugs in this code as we work through refactoring it. If the answer to the above questions are “No”, it’s likely revenue generating code (or part of some compliance process). In this case the “other side” is non-technical stakeholders who don’t inherently understand the importance of resolving technical debt.

philwelch 7y ago

If you buy thousands of dollars of unnecessary crap with your credit card, you’re still in “debt”, so the analogy still holds.

romwell 7y ago

>What you have instead is knowledge debt as engineers turn over ... This isn’t tech debt You know, if there only were a way to pass knowledge from one person to another aside from directly talking to that person. Perhaps if we had means of preserving knowledge, and even making it a part of the job description... But alas. Joking aside, not writing technical documentation and product design docs is very much technical debt. A lot of information that is lost with turnover is information that could have been written down and passed on. Documentation is not jut code comments. It is: -A solid bug tracking system, with clean and reproducible bug descriptions -A version control history, where every change has a why in addition to a brief how, and which links with the bug tracker -Well-written tests, which not only verify how a system works, but showcase how to use the APIs. -Documentation for tests explaining why this input was chosen, what kind of output is expected, and why it was written that way -High level comments in code (especially libraries) explaining how the API should be used -High level documentation explaining the structure of the code that is checked in, and lives with the code. The documentation can be in Markdown or a plaintext README, but should be there -A "code map" telling you what the code in various directories does, and where to look for things. -And, most importantly, a lot of design docs - for every feature and algorithm. "We are solving this problem. Here are the alternatives considered. Here is what we are going to do and why. Here is how we'll implement this. We used ideas from this, this, and this paper". Yes, all of that is needed. The price you pay is engineering time. But if you take on the debt, your new engineers will have Hours Of Fun[1] trying to figure out, say, whether the imaginary nanometers[2] model parameter increasing as a result of their change is a good or a bad thing. What I am saying is documentation debt is technical debt. Documentation is just as important as the code. And having it does help[3]. You might think that your code doesn't need all of that. And that's fine; but that means you plan on never paying that debt. Maybe you plan for your startup to fail/sell out in a few years. Maybe you plan to leave that job. But anything long term means you have to write things down. And if you haven't been doing so - now is as good time as ever to start. [1]http://wiki.c2.com/?HoursOfFun http://wiki.c2.com/?HoursOfFun [2]True story. There was a good reason for why the distance parameter had complex-valued nanometers as units; it was an elegant way to do improve a model while staying backwards-compatible. It was written down nowhere, and have fun googling "complex nanometers". They only exist in that code, AFAIK.

7y ago

martin_ 7y ago

This is great and well articulated! Would you agree legacy code can often turn into tech debt by virtue of being neglected / unmaintained? The debt here could perhaps be measured by operational overhead

JamesBarney 7y ago

> Making poor architectural decisions or writing poor quality code isn’t tech debt I think it is. Technical debt is all about trading current productivity for future productivity. Poor architectural decisions can be caused by several factors. Inexperienced devs, not taking enough time to understand problem, not spending enough time brainstorming the problem. These are all decisions that trade current productivity for future productivity, which is technical debt. Also most technical debt is not accrued consciously. Very few people are doing cost benefit analysis on technical debt. It's usually made intuitively by project and product managers who don't directly interact with the costs of technical debt but directly experience the benefits.

collyw 7y ago
> Inexperienced devs, not taking enough time to understand problem, not spending enough time brainstorming the problem Requirements changing is also a big one. 4 years into one project that I had created and maintained a "one to many" relationship changed to a "many to many" in some of the tables central to the system. Something that I had clarified wouldn't when originally designing the system.
tremon 7y ago
> Technical debt is all about trading current productivity for future productivity. This is a very succinct and accurate description, and one I haven't come across. Thank you for this phrasing :)

dep_b 7y ago

The goal of an MVP is not to write crappy code to get something quickly out of the door but to not build every feature into all details to get all of the parts together and see how they work first. It's about the code you don't write, not about the quality of what you do write.

SkyBelow 7y ago

>Making poor architectural decisions or writing poor quality code isn’t tech debt. I compare technical debt to debt. You may go in debt because you looked at the housing market and decided that now is likely a good time to buy a house with low interest rates. You take on a large load of debt, but it is done wisely based on currently information. You may go in debt as a business operating on credit to fund an expansion that should pay off quite nicely in a few years time. Maybe it will fail, but it isn't a bad risk based on current knowledge. You may go in debt for an education. Depending upon the degree and extent of debt this could be good or bad. You may go in debt by spending beyond your means on a credit card. This is generally unwise. You may go in debt because of a medical emergency that is entirely beyond your control (especially in some countries, but even some countries with universal healthcare it is possible to need treatment that isn't covered). All of these have something similar when dealing with technical debt. Sometimes it is a wise investment. Sometimes it is a risk that may or may not pay off. Sometimes it is beyond one's control. Sometimes it is poor planning that will be regretted later.

jkoudys 7y ago

Yeah, I see too often devs shrug off their "technical debt" when what they're really describing is simply sloppy work. These economic metaphors always break down when you challenge the idea that devs/dev managers are always acting in the best interest of the product. I've seen teams cheer their "velocity" because they're closing lots of issues, when most of the things they're focused on shouldn't have even been an issue in the first place. For the cases like legacy code and turnover, perhaps "tech depreciation" is the more appropriate economic term. You didn't really borrow against the future to have more today, rather something naturally decreases in value over time.

olooney 7y ago
Right. Technical debt should not be understood on its own but as part of a larger "technical balance sheet" metaphor: technical depreciation, technical amortization, and so on.

goto11 7y ago

Technical debt is a great metaphor exactly because it suggest the suboptimal code is due to a deliberate strategic decision. If you just say that some code is bad you will get unproductive reactions like people getting defensive, trying to assign blame etc. Calling it technical debt allow you to call attention to an issue while avoiding blaming anybody.

kalecserk 7y ago

Great comment, if you allow I would summarize by rephrasing one sentence making it shorter: What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future. That is it! Thank you for sharing your thoughts.

dragonwriter 7y ago

> Legacy code isn’t tech debt either: it was right for the time. The time it was written often isn't when the technical debt was incurred, when maintenance to keep it right, technologically, for the changing time was deferred, that's when a decision was made to incur a higher price later to save now: that's when the (technical) debt was incurred. > as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities The existence of technical debt is unrelated to awareness of the deferred costs. “technical debt” isn't a statement about the existing technical staff’s perception of the system.