22 ms·

I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than unders

I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand”. (The rest of the time is the same but they’ve understood it enough to think it’s a disaster area.) I have found it’s best to not take tech debt complaints very seriously and instead look at actual success metrics. For example if every change to a bit of code introduces new bugs then that might be a reason to tidy it up.

technobabble 8y ago
What success metrics do you use?
- ghiculescu 8y ago
  Hard to give a one size fits all answer, it depends on your project. But some examples: - speed of delivery (not so much hitting a public deadline as shipping it as fast as you thought you could internally) - quality of final product (were there delighters that didn't get built because they were too hard) - number of follow up bug fixes shipped shortly after the main project ships (did we ship a bunch of bugs and not realise until users found them) - number of new users acquired from shipping the feature
  - waterlink 8y ago
    As a Lean practitioner, I love the last one: > number of new users acquired from shipping the feature
  - Jach 8y ago
    How are you measuring these things? 1. It's one of my dreams to work at a place using prediction markets for internal estimates. Anything else feels worthless and engineers are incentivized into the "quadruple what you're currently thinking" estimate so they more often meet deadlines -- or try to "under-promise, over-deliver" except management rightly catch on to that one immediately. (As an engineer I still want to be a La Forge and work with other La Forges, even if Scotty[0] sometimes has a point; modeling managers as demanding children has some gaping model gaps.) 2. What I've seen is that many delighters aren't that hard, but they're often treated as "polish" that goes into the p3/p4 priority backlogs and maybe might resurface if a customer ever brings up a desire for that to the product management. What delighters have you seen that weren't shipped because they were too hard? Were they actually too hard, or was it just too much to get them done by some release date alongside all the other stuff so they get shoved to the backlog just the same? 3. Are you measuring bug count based on what customers report or internal bug reports? If internal, even if people aren't gaming this directly, it's still easy to get into a bad cycle where reported bugs get ignored and go unfixed which leads to fewer reported bugs. That might be mistaken for higher quality. 4. Is this one measured from surveys? Obviously not all features are directly customer visible so let's take something concrete like shipping an Observer mode for an RTS video game that shipped its big release a couple months ago. How would you measure the impact of getting new users from that one feature? [0] https://www.youtube.com/watch?v=8xRqXYsksFg https://www.youtube.com/watch?v=8xRqXYsksFg
Balero 8y ago
Whilst I find that this is definitely a good portion of technical debt, the biggest section I see comes from the intersection of reusing code and moving requirements. Often when some code reuse gets nested (re-using something that is re-using something), then having to tweak it a little at the end to get to the right state. Basically a bunch of development is done towards a local maximum. But looking at it as tech debt can bring it up to a global maximum.
dsfyu404ed 8y ago
>I’d rather rewrite than understand The people with this attitude seem to be the best sources of hard to understand legacy code.
- waterlink 8y ago
  That is true. While I have to agree that it takes the pain and struggle to understand some code out there, it is still worth doing, and a good indicator of the quality of the code, and the fact that it needs improvement. Also, I believe leaving some “bad code” without understanding it, and just rewriting it, _might be_ unprofessional…
maxxxxx 8y ago
Totally agree. And often if you make the effort to understand the code you can refactor it with reasonable effort to address the real problems. A lot of rewrites I have seen just traded one set of problems with a different set of problems.
- carlmr 8y ago
  I like the boy scout rule. Clean up and leave it nicer than you found it. Focused mostly on things related to your change. Big rewrites cause big issues.
  - pmarreck 8y ago
    > Big rewrites cause big issues. Those issues are very much constrained by a very good test suite.
    - waterlink 8y ago
      Unless your test suite needs a rewrite, as well… (Better refactor, of course)
      - camgunz 8y ago
        Your test suite should essentially be your requirements. If it's out of date, it's the first thing you should update. Adding features or changing your requirements without updating your tests is the essence of tech debt: you're delivering features quickly at the expense of future work and brittleness. I agree it's pretty common though. I've also seen huge test suites of only unit tests, no integration tests. As a result, you have no assurance that your refactors work because changing the inner workings fundamentally requires you to change the unit tests too, and nothing checks the top-level interface.
      - Shorel 8y ago
        You either rewrite the tests, or the code. Not both at the same time, in my opinion.
    - 8y ago
Bahamut 8y ago
I’ve never seen technical debt referred to such at any workplace - all the time I’ve seen the term used to refer to poor or outdated design decisions that compromise the ability to deliver on business objectives in serious ways. Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues before it is too late and everything is on fire all the time. Be wary of any such blanket assumptions in engineering.
- waterlink 8y ago
  > Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues Would you agree that we should think about specific issues that are slowing us down, and fix them one by one, starting from the worst ones? (worst in sense of biggest slowdown/pain levels)
  - Bahamut 8y ago
    Sure, but my point was one should consider complaints as signal that the situation should be monitored/investigated so that the general outlines of an actionable plan can be crafted if there are potential areas of risk, or in the most serious situation, an actual plan. Blanket painting of a class of complaints doesn't help them or you accomplish business objectives better long term.
    - ghiculescu 8y ago
      We agree more than you think. Most complaints about tech debt are not worth actioning, but that doesn't mean you shouldn't listen to all of them and try to filter the signal from the noise.
- repolfx 8y ago
  Lucky you :) I think there's a reason that post is currently voted to the top. I'm lead engineer on my startup's project, not the CTO but reporting directly to him. Team of about 30. There are of course many legitimate things that can be described as tech debt, files that got too large and convoluted over many patches by many people, that sort of thing. But I find I have to watch out for the concept of "tech debt" because a few engineers will abuse it if given the chance. For instance they will insist that code that was just written fresh by a colleague is "tech debt" because they would personally have written it differently, when there are no meaningful differences between the two approaches. They can claim that a design they don't understand the reasons for immediately (regardless of whether it's documented) is tech debt. They can claim any feature they don't personally want to do or which is perceived as hard work will create tech debt. And so on. I wrote the initial code and I'm close enough to the codebase still to be able to fairly thoroughly examine claims of tech debt. I'd say most such claims are actually not a big deal and do not justify any non-trivial investments of time to resolve. Moreover the sort of engineers who pay down more than their fair share of legitimate tech debt are invariably the ones who complain about it the least.
mabbo 8y ago
> “code someone else wrote that I’d rather rewrite than understand” I'm not disagreeing, but there is something to be said for writing code that any idiot can understand so that future developers don't even want to rewrite it, and can maintain it. I've landed in code bases on both ends of the spectrum, and I never asked management to rewrite the well-written ones.
- maxxxxx 8y ago
  There is a level of luck involved in producing well written code. Sometimes your assumptions turn out to be correct and sometimes a big requirements change comes and turns your code from simple to super complex.
  - MaxBarraclough 8y ago
    Sure, a giant-ball-of-mud codebase might be the result of changing requirements and assumptions, but it could be the result of laziness/unskilled development. There's a skill to writing readable, ideally self-documenting code. If that skill is wanting, even the most stable requirements won't save you from the mud.
    - maxxxxx 8y ago
      Correct. But don't forget that it can also go the other way. The best code writing skills can be defeated by ever changing requirements. Besides code writing there is a also a skill in being disciplined about requirements changes.
    - mixmastamyk 8y ago
      > could be the result of laziness/unskilled development. Or not being allowed/kept too busy to fix it.
- waterlink 8y ago
  It seems like: “rewrite” is in sense of “I don’t even want to understand it, going to just delete it, and implement anew”, VS “refactor” is in sense of “I had to spend quite a while trying to understand this code, and I think it can be improved, so that the next developer doesn’t have to spend this time.”
leejo 8y ago
> I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand” IME it can be one of many things, including but not limited to: was written by someone who is no longer with the company, doesn't have (relatively comprehensive) tests, doesn't have any documentation, commit messages don't explain the codes' reason for being, is a blocker to getting more lucrative features out, nobody understands it ergo nobody dares touch it, written in a language that is hard to recruit new devs for, is working fine now but will be a problem in x months/years time, contains potential WFIO points but is business critical, is difficult to scale, and possibly more. What i'm saying in the above is that it's possible to write something in a easy to recruit for language, that scales well, is comprehensively tested, has no nasty bugs, but could still be considered technical debt because the original developer(s) wrote useless commit messages, no documentation, and then left the company.
sockgrant 8y ago
Yep. I’ve seen this in a number of startups. Didn’t see it as much at big firms. Reading code is harder than writing code. So, IMO, lazy or slow engineers would rather complain that code should be rewritten than refactored. Or that different frameworks / languages should be used. Ive entertained them a few times before realizing that it was a waste of time and often things came out worse.
- talmand 8y ago
  I don't think I would agree with the usage of the word "lazy" to describe coders that want to rewrite entire chunks of code. They may have their invalid reasons for wanting to do so, but I wouldn't call that being lazy.
  - deleted 8y ago
    [deleted]
- bjconlan 8y ago
  Yeah, I feel that this is by and large the scenario I've witnessed. Not necessarily pushed by slow/lazy engineers but those that are bored with tried and true solutions that have some 'difficult corners to chamfer'. I think the problem with developers is that they want to solve a problem in a very recognisable pattern playing into the Asperger's like nature held by most perfectionists but unfortunately ends up much like your have outlined (but now they have some hot new technology on there resume so moving onto different problems is usually more desirable than re-fixing the new problems they've introduced to solve again)
phyller 8y ago
From this point of view, I guess you should make an exception and treat tech debt complaints more seriously when it is coming from the devs who wrote the original code. Sometimes in order to meet business needs and get things out the door you have to cut corners that you need to go back and take care of later, or you are crippling the future growth and stability of the project. I like your final point "if every change to a bit of code introduces new bugs then that might be a reason to tidy it up". I think sometimes proper testing is the first thing to go in a time crunch, and good tests improve velocity. If you know that the entire app is being tested automatically, you can develop a lot faster and more fearlessly. Plus writing good tests inherently makes the original code better. You find and fix hidden bugs, and you refactor the code to be more testable which makes it better in other ways.
- waterlink 8y ago
  > From this point of view, I guess you should make an exception and treat tech debt complaints more seriously when it is coming from the devs who wrote the original code. Oh, that is quite an interesting idea. If the author themselves acknowledges there is a problem—there should be a real problem.
  - convolvatron 8y ago
    the other way works too. any developer should be able to discuss at length the compromises made and the weak aspects of any project. every piece of software has a long list of potential improvements in clarity, verification, efficiency, generality, etc. when I first heard the term 'technical debt', I thought it was fantastic that we had a shared name. but as someone else pointed out in this thread, the normal compromises one makes because of schedule and lack of importance are really a different thing entirely than a codebase that is failing structurally. normal compromises can be ignored, and often aren't even compositional. thats the kind of linear, easily repairable stuff I think should be called 'debt', and it isn't scary at all. you overcome it at some later date when and if it makes sense. maybe debt isn't the right word, because you aren't borrowing failure from some abstract ideal, you're just choosing to trade of time for quality, which every effort in every field has to do. structural issues that compound exponentially, and make it increasingly difficult to make any changes at all are a different thing (call it 'crippling debt', idk). its a metastatic cancer and can easily be fatal.
digikata 8y ago
If you think it's mostly unfamiliarity, then that's a great opportunity to suggest some time spent to document that code (and/or operations thru that code). It helps w/ the understanding, and should be a precursor to figuring out if a redesign could help that "tech debt".
corobo 8y ago
I more see technical debt as "// TODO: Refactor this into its own class rather than do it here" written by a dev 4 devs ago
thiagooffm 8y ago
You sir. Have no idea about software development. Extensibility is just as important as Bugfree software for some businesses. Actually, for most of them. Technical debt hurts much more the extensibility of your code rather than raises the number of bugs.
- deleted 8y ago
  [deleted]
fhood 8y ago
This doesn't match my observations at all. In fact, way more importantly, often what is being shouted is, "we are creating more technical debt than we can possibly handle by doing X in Y way to meet Z deadline, this is going to bite you in the ass after we all switch teams/companies because nobody wants to deal with this." Edit: If developers are warning the CTO that there is an issue with technical debt that should be a warning flag. Particularly if these are senior/experienced developers who understand the insane costs of re-writing production code.
- ghiculescu 8y ago
  > we are creating more technical debt than we can possibly handle by doing X in Y way to meet Z deadline, this is going to bite you in the ass after we all switch teams/companies because nobody wants to deal with this This one doesn't require you to read between the lines, people usually just tell me that directly :) Your mileage may vary - in my experience this is another one of things where it's not actually true most of the time. Note how it's a really easy to claim to make, and basically impossible to disprove ("at some unknown time in the future something bad will happen unless you let me have my cake now"). To me that's a warning sign that it might be wrong. As a leader (or CTO or whatever) your job is to make the call. And if it turns out you were wrong and there is literally nobody who wants to touch the mess, well the buck stops with you and you have to clean it up. I'm happy to take that bet!
  - nojvek 8y ago
    Or you know, the CTO could quit. I’ve seen this happen multiple times. Teams are in max feature mode, introducing a ton of code duplication, inconsistent abstractions and hidden assumptions. Team members get fat bonuses. For the next round of features, they can’t be as fast since they have to fix the mess they created to add new things without breaking old ones. So one by one they start switching to the team working on the shiny thing. New developers are hired, they realize the mess and nop out. The harsh truth, which is evident from the thread, very few companies/managers actually reward fixing code debt.
deleted 8y ago
[deleted]
ex_amazon_sde 8y ago
> "code someone else wrote that I’d rather rewrite than understand" I've never seen this happening but it seems to be common in hipster environments. Do not hire people that want to rewrite something just because it's not written in the popular language/framework of the year.
mcv 8y ago
I think technical debt is a bit more complex than merely "somebody else's code". I've also written code that increased technical debt. I hated it, but when there's a hard deadline and not enough time, it's unavoidable. Better planning and coordination can prevent a lot of technical debt. But mostly, it's decisions that seemed to make sense at the time, but now turn out to be wrong. Or simply the accumulation of fix upon fix, feature upon feature, without without doing a redesign based on changing requirements or lessons learned. If you don't work to stop it, entropy will add up and eventually turns the code into an unmaintainable mess.
JamesBarney 8y ago
100% agreed. Most code complaints are this code sucks. But honestly most code looks like shit, and battle tested code that's been heavily patched to work well and cover lots of special cases especially lookS like shit. But when there is a documented problem with a piece of code that is important and worth refactoring because it can't be mediated otherwise then of course you need to fix it. For example recently a previous dev split the data model across persisted HTML and rows in a database. Which means it was very easy for the domain critical computations(driven by the database) to display one set of inputs to the user, but calculate with another.
deleted 8y ago
[deleted]
ben_jones 8y ago
Nothing like the smell of software design truth bombs in the morning. I'd add "this code I wrote is technical debt because I'd rather re-write it then create a proper test harness for all its bugs and edge cases".
Buttons840 8y ago
> a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand” There's a paradox in this viewpoint. On the one hand you believe that your developers are so immature that they automatically shout "tech debt" for any code they didn't personally write ("only MY code is good"), then on the other hand you're confident that the code produced by these immature developers is actually just fine and doesn't have any technical debt. I know you're not speaking in absolutes, so you may be right. You especially may be right about your own specific situation. However, I think a lot of people who have this viewpoint are simply kidding themselves into believing that "everything is awesome, surely there couldn't be any problems because I am the team lead". Just remember the general form of the argument is "my team is great and talented, but I can't trust what they're telling me". It might be the case, but be careful of your own biases.
- itsdrewmiller 8y ago
  This is not a paradox (or a contradiction). Many developers prefer writing code to reading code. They may be perfectly good at both, and still err on the side of claiming that they need to write code rather than read it.
  - deleted 8y ago
    [deleted]
- jibal 8y ago
  You mean contradiction, not paradox. (A paradox is a contradiction that can't be resolved because both branches seem to be undeniable.) The contradiction stems from hyperbole (a type of lying) and other forms of nefarious (insincere, intellectually dishonest, aimed at winning rather than truth-seeking) rhetoric.
lvncelot 8y ago
I'm sorry, but if you are going to dismiss a co-workers opinion like that, it seems like you don't value their work at all. Do you trust them enough to write decent code, but not enough to value their concerns? That doesn't seem fair to them.
Shorel 8y ago
Do new developers in a project really use that term? In my experience it is used by senior developers having dealt with the same systems for years. But I don't work in a fancy startup or similar. YMMV.
hinkley 8y ago
This isn’t a comparative literature class. I don’t have the luxury of spending all day savoring the clever hack you put in your code. I’m trying to fix a bug or add a feature. All the frippery just pulls me away from the problem at hand. There was an agile coach I heard an interview with who insisted that Tech Debt was the wrong analogy. He preferred Wear and Tear. I think the problems of kludgy or overclever code are more apparent if you think of it that way. At the very least, the main thoroughfares of the codebase need to be clean and free of dangerous obstacles.
refulgentis 8y ago
This is _so_ true. I have a unique career, no CS education, built a startup to scratch my itch, had no teammates on my codebase, worked on it for 5 years, sold it, now I've been at (insert FANG) for 2 years. On my own, I would look at code I wrote 6 months ago, wonder what idiot wrote that, then figure out if it was actually bad, or I just didn't understand it. With staff turnover and a lack of incentive for engineers to prioritize shipping (thats the manager and PM's problem), there's a heavy bias to "It's bad, rewrite it" rather than "Oh, it gets the job done, I just didn't understand it, let me research and comment the code". _Tons_ of time is wasted.
muzani 8y ago
If that's the case, it should be documented better. Not documented more though. Too often, people add too much documentation to the point nobody reads it. Instead of rewriting the code, there should be some effort to show figure out how it links and how it works together.
fnl 8y ago
Interesting that this reply is voted highest, as it doesn't actually answer the question, but rather suggest to ignore the entire issue.

technobabble 8y ago

What success metrics do you use?

ghiculescu 8y ago
Hard to give a one size fits all answer, it depends on your project. But some examples: - speed of delivery (not so much hitting a public deadline as shipping it as fast as you thought you could internally) - quality of final product (were there delighters that didn't get built because they were too hard) - number of follow up bug fixes shipped shortly after the main project ships (did we ship a bunch of bugs and not realise until users found them) - number of new users acquired from shipping the feature
- waterlink 8y ago
  As a Lean practitioner, I love the last one: > number of new users acquired from shipping the feature
- Jach 8y ago
  How are you measuring these things? 1. It's one of my dreams to work at a place using prediction markets for internal estimates. Anything else feels worthless and engineers are incentivized into the "quadruple what you're currently thinking" estimate so they more often meet deadlines -- or try to "under-promise, over-deliver" except management rightly catch on to that one immediately. (As an engineer I still want to be a La Forge and work with other La Forges, even if Scotty[0] sometimes has a point; modeling managers as demanding children has some gaping model gaps.) 2. What I've seen is that many delighters aren't that hard, but they're often treated as "polish" that goes into the p3/p4 priority backlogs and maybe might resurface if a customer ever brings up a desire for that to the product management. What delighters have you seen that weren't shipped because they were too hard? Were they actually too hard, or was it just too much to get them done by some release date alongside all the other stuff so they get shoved to the backlog just the same? 3. Are you measuring bug count based on what customers report or internal bug reports? If internal, even if people aren't gaming this directly, it's still easy to get into a bad cycle where reported bugs get ignored and go unfixed which leads to fewer reported bugs. That might be mistaken for higher quality. 4. Is this one measured from surveys? Obviously not all features are directly customer visible so let's take something concrete like shipping an Observer mode for an RTS video game that shipped its big release a couple months ago. How would you measure the impact of getting new users from that one feature? [0] https://www.youtube.com/watch?v=8xRqXYsksFg https://www.youtube.com/watch?v=8xRqXYsksFg

Balero 8y ago

Whilst I find that this is definitely a good portion of technical debt, the biggest section I see comes from the intersection of reusing code and moving requirements. Often when some code reuse gets nested (re-using something that is re-using something), then having to tweak it a little at the end to get to the right state. Basically a bunch of development is done towards a local maximum. But looking at it as tech debt can bring it up to a global maximum.

dsfyu404ed 8y ago

>I’d rather rewrite than understand The people with this attitude seem to be the best sources of hard to understand legacy code.

waterlink 8y ago
That is true. While I have to agree that it takes the pain and struggle to understand some code out there, it is still worth doing, and a good indicator of the quality of the code, and the fact that it needs improvement. Also, I believe leaving some “bad code” without understanding it, and just rewriting it, _might be_ unprofessional…

maxxxxx 8y ago

Totally agree. And often if you make the effort to understand the code you can refactor it with reasonable effort to address the real problems. A lot of rewrites I have seen just traded one set of problems with a different set of problems.

carlmr 8y ago
I like the boy scout rule. Clean up and leave it nicer than you found it. Focused mostly on things related to your change. Big rewrites cause big issues.
- pmarreck 8y ago
  > Big rewrites cause big issues. Those issues are very much constrained by a very good test suite.
  - waterlink 8y ago
    Unless your test suite needs a rewrite, as well… (Better refactor, of course)
    - camgunz 8y ago
      Your test suite should essentially be your requirements. If it's out of date, it's the first thing you should update. Adding features or changing your requirements without updating your tests is the essence of tech debt: you're delivering features quickly at the expense of future work and brittleness. I agree it's pretty common though. I've also seen huge test suites of only unit tests, no integration tests. As a result, you have no assurance that your refactors work because changing the inner workings fundamentally requires you to change the unit tests too, and nothing checks the top-level interface.
    - Shorel 8y ago
      You either rewrite the tests, or the code. Not both at the same time, in my opinion.
  - 8y ago

Bahamut 8y ago

I’ve never seen technical debt referred to such at any workplace - all the time I’ve seen the term used to refer to poor or outdated design decisions that compromise the ability to deliver on business objectives in serious ways. Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues before it is too late and everything is on fire all the time. Be wary of any such blanket assumptions in engineering.

waterlink 8y ago
> Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues Would you agree that we should think about specific issues that are slowing us down, and fix them one by one, starting from the worst ones? (worst in sense of biggest slowdown/pain levels)
- Bahamut 8y ago
  Sure, but my point was one should consider complaints as signal that the situation should be monitored/investigated so that the general outlines of an actionable plan can be crafted if there are potential areas of risk, or in the most serious situation, an actual plan. Blanket painting of a class of complaints doesn't help them or you accomplish business objectives better long term.
  - ghiculescu 8y ago
    We agree more than you think. Most complaints about tech debt are not worth actioning, but that doesn't mean you shouldn't listen to all of them and try to filter the signal from the noise.
repolfx 8y ago
Lucky you :) I think there's a reason that post is currently voted to the top. I'm lead engineer on my startup's project, not the CTO but reporting directly to him. Team of about 30. There are of course many legitimate things that can be described as tech debt, files that got too large and convoluted over many patches by many people, that sort of thing. But I find I have to watch out for the concept of "tech debt" because a few engineers will abuse it if given the chance. For instance they will insist that code that was just written fresh by a colleague is "tech debt" because they would personally have written it differently, when there are no meaningful differences between the two approaches. They can claim that a design they don't understand the reasons for immediately (regardless of whether it's documented) is tech debt. They can claim any feature they don't personally want to do or which is perceived as hard work will create tech debt. And so on. I wrote the initial code and I'm close enough to the codebase still to be able to fairly thoroughly examine claims of tech debt. I'd say most such claims are actually not a big deal and do not justify any non-trivial investments of time to resolve. Moreover the sort of engineers who pay down more than their fair share of legitimate tech debt are invariably the ones who complain about it the least.

mabbo 8y ago

> “code someone else wrote that I’d rather rewrite than understand” I'm not disagreeing, but there is something to be said for writing code that any idiot can understand so that future developers don't even want to rewrite it, and can maintain it. I've landed in code bases on both ends of the spectrum, and I never asked management to rewrite the well-written ones.

maxxxxx 8y ago
There is a level of luck involved in producing well written code. Sometimes your assumptions turn out to be correct and sometimes a big requirements change comes and turns your code from simple to super complex.
- MaxBarraclough 8y ago
  Sure, a giant-ball-of-mud codebase might be the result of changing requirements and assumptions, but it could be the result of laziness/unskilled development. There's a skill to writing readable, ideally self-documenting code. If that skill is wanting, even the most stable requirements won't save you from the mud.
  - maxxxxx 8y ago
    Correct. But don't forget that it can also go the other way. The best code writing skills can be defeated by ever changing requirements. Besides code writing there is a also a skill in being disciplined about requirements changes.
  - mixmastamyk 8y ago
    > could be the result of laziness/unskilled development. Or not being allowed/kept too busy to fix it.
waterlink 8y ago
It seems like: “rewrite” is in sense of “I don’t even want to understand it, going to just delete it, and implement anew”, VS “refactor” is in sense of “I had to spend quite a while trying to understand this code, and I think it can be improved, so that the next developer doesn’t have to spend this time.”

leejo 8y ago

> I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand” IME it can be one of many things, including but not limited to: was written by someone who is no longer with the company, doesn't have (relatively comprehensive) tests, doesn't have any documentation, commit messages don't explain the codes' reason for being, is a blocker to getting more lucrative features out, nobody understands it ergo nobody dares touch it, written in a language that is hard to recruit new devs for, is working fine now but will be a problem in x months/years time, contains potential WFIO points but is business critical, is difficult to scale, and possibly more. What i'm saying in the above is that it's possible to write something in a easy to recruit for language, that scales well, is comprehensively tested, has no nasty bugs, but could still be considered technical debt because the original developer(s) wrote useless commit messages, no documentation, and then left the company.

sockgrant 8y ago

Yep. I’ve seen this in a number of startups. Didn’t see it as much at big firms. Reading code is harder than writing code. So, IMO, lazy or slow engineers would rather complain that code should be rewritten than refactored. Or that different frameworks / languages should be used. Ive entertained them a few times before realizing that it was a waste of time and often things came out worse.

talmand 8y ago
I don't think I would agree with the usage of the word "lazy" to describe coders that want to rewrite entire chunks of code. They may have their invalid reasons for wanting to do so, but I wouldn't call that being lazy.
- deleted 8y ago
  [deleted]
bjconlan 8y ago
Yeah, I feel that this is by and large the scenario I've witnessed. Not necessarily pushed by slow/lazy engineers but those that are bored with tried and true solutions that have some 'difficult corners to chamfer'. I think the problem with developers is that they want to solve a problem in a very recognisable pattern playing into the Asperger's like nature held by most perfectionists but unfortunately ends up much like your have outlined (but now they have some hot new technology on there resume so moving onto different problems is usually more desirable than re-fixing the new problems they've introduced to solve again)

phyller 8y ago

From this point of view, I guess you should make an exception and treat tech debt complaints more seriously when it is coming from the devs who wrote the original code. Sometimes in order to meet business needs and get things out the door you have to cut corners that you need to go back and take care of later, or you are crippling the future growth and stability of the project. I like your final point "if every change to a bit of code introduces new bugs then that might be a reason to tidy it up". I think sometimes proper testing is the first thing to go in a time crunch, and good tests improve velocity. If you know that the entire app is being tested automatically, you can develop a lot faster and more fearlessly. Plus writing good tests inherently makes the original code better. You find and fix hidden bugs, and you refactor the code to be more testable which makes it better in other ways.

waterlink 8y ago
> From this point of view, I guess you should make an exception and treat tech debt complaints more seriously when it is coming from the devs who wrote the original code. Oh, that is quite an interesting idea. If the author themselves acknowledges there is a problem—there should be a real problem.
- convolvatron 8y ago
  the other way works too. any developer should be able to discuss at length the compromises made and the weak aspects of any project. every piece of software has a long list of potential improvements in clarity, verification, efficiency, generality, etc. when I first heard the term 'technical debt', I thought it was fantastic that we had a shared name. but as someone else pointed out in this thread, the normal compromises one makes because of schedule and lack of importance are really a different thing entirely than a codebase that is failing structurally. normal compromises can be ignored, and often aren't even compositional. thats the kind of linear, easily repairable stuff I think should be called 'debt', and it isn't scary at all. you overcome it at some later date when and if it makes sense. maybe debt isn't the right word, because you aren't borrowing failure from some abstract ideal, you're just choosing to trade of time for quality, which every effort in every field has to do. structural issues that compound exponentially, and make it increasingly difficult to make any changes at all are a different thing (call it 'crippling debt', idk). its a metastatic cancer and can easily be fatal.

digikata 8y ago

If you think it's mostly unfamiliarity, then that's a great opportunity to suggest some time spent to document that code (and/or operations thru that code). It helps w/ the understanding, and should be a precursor to figuring out if a redesign could help that "tech debt".

corobo 8y ago

I more see technical debt as "// TODO: Refactor this into its own class rather than do it here" written by a dev 4 devs ago

thiagooffm 8y ago

You sir. Have no idea about software development. Extensibility is just as important as Bugfree software for some businesses. Actually, for most of them. Technical debt hurts much more the extensibility of your code rather than raises the number of bugs.

deleted 8y ago
[deleted]

fhood 8y ago

This doesn't match my observations at all. In fact, way more importantly, often what is being shouted is, "we are creating more technical debt than we can possibly handle by doing X in Y way to meet Z deadline, this is going to bite you in the ass after we all switch teams/companies because nobody wants to deal with this." Edit: If developers are warning the CTO that there is an issue with technical debt that should be a warning flag. Particularly if these are senior/experienced developers who understand the insane costs of re-writing production code.

ghiculescu 8y ago
> we are creating more technical debt than we can possibly handle by doing X in Y way to meet Z deadline, this is going to bite you in the ass after we all switch teams/companies because nobody wants to deal with this This one doesn't require you to read between the lines, people usually just tell me that directly :) Your mileage may vary - in my experience this is another one of things where it's not actually true most of the time. Note how it's a really easy to claim to make, and basically impossible to disprove ("at some unknown time in the future something bad will happen unless you let me have my cake now"). To me that's a warning sign that it might be wrong. As a leader (or CTO or whatever) your job is to make the call. And if it turns out you were wrong and there is literally nobody who wants to touch the mess, well the buck stops with you and you have to clean it up. I'm happy to take that bet!
- nojvek 8y ago
  Or you know, the CTO could quit. I’ve seen this happen multiple times. Teams are in max feature mode, introducing a ton of code duplication, inconsistent abstractions and hidden assumptions. Team members get fat bonuses. For the next round of features, they can’t be as fast since they have to fix the mess they created to add new things without breaking old ones. So one by one they start switching to the team working on the shiny thing. New developers are hired, they realize the mess and nop out. The harsh truth, which is evident from the thread, very few companies/managers actually reward fixing code debt.

deleted 8y ago

[deleted]

ex_amazon_sde 8y ago

> "code someone else wrote that I’d rather rewrite than understand" I've never seen this happening but it seems to be common in hipster environments. Do not hire people that want to rewrite something just because it's not written in the popular language/framework of the year.

mcv 8y ago

I think technical debt is a bit more complex than merely "somebody else's code". I've also written code that increased technical debt. I hated it, but when there's a hard deadline and not enough time, it's unavoidable. Better planning and coordination can prevent a lot of technical debt. But mostly, it's decisions that seemed to make sense at the time, but now turn out to be wrong. Or simply the accumulation of fix upon fix, feature upon feature, without without doing a redesign based on changing requirements or lessons learned. If you don't work to stop it, entropy will add up and eventually turns the code into an unmaintainable mess.

JamesBarney 8y ago

100% agreed. Most code complaints are this code sucks. But honestly most code looks like shit, and battle tested code that's been heavily patched to work well and cover lots of special cases especially lookS like shit. But when there is a documented problem with a piece of code that is important and worth refactoring because it can't be mediated otherwise then of course you need to fix it. For example recently a previous dev split the data model across persisted HTML and rows in a database. Which means it was very easy for the domain critical computations(driven by the database) to display one set of inputs to the user, but calculate with another.

deleted 8y ago

[deleted]

ben_jones 8y ago

Nothing like the smell of software design truth bombs in the morning. I'd add "this code I wrote is technical debt because I'd rather re-write it then create a proper test harness for all its bugs and edge cases".

Buttons840 8y ago

> a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand” There's a paradox in this viewpoint. On the one hand you believe that your developers are so immature that they automatically shout "tech debt" for any code they didn't personally write ("only MY code is good"), then on the other hand you're confident that the code produced by these immature developers is actually just fine and doesn't have any technical debt. I know you're not speaking in absolutes, so you may be right. You especially may be right about your own specific situation. However, I think a lot of people who have this viewpoint are simply kidding themselves into believing that "everything is awesome, surely there couldn't be any problems because I am the team lead". Just remember the general form of the argument is "my team is great and talented, but I can't trust what they're telling me". It might be the case, but be careful of your own biases.

itsdrewmiller 8y ago
This is not a paradox (or a contradiction). Many developers prefer writing code to reading code. They may be perfectly good at both, and still err on the side of claiming that they need to write code rather than read it.
- deleted 8y ago
  [deleted]
jibal 8y ago
You mean contradiction, not paradox. (A paradox is a contradiction that can't be resolved because both branches seem to be undeniable.) The contradiction stems from hyperbole (a type of lying) and other forms of nefarious (insincere, intellectually dishonest, aimed at winning rather than truth-seeking) rhetoric.

lvncelot 8y ago

I'm sorry, but if you are going to dismiss a co-workers opinion like that, it seems like you don't value their work at all. Do you trust them enough to write decent code, but not enough to value their concerns? That doesn't seem fair to them.

Shorel 8y ago

Do new developers in a project really use that term? In my experience it is used by senior developers having dealt with the same systems for years. But I don't work in a fancy startup or similar. YMMV.

hinkley 8y ago

This isn’t a comparative literature class. I don’t have the luxury of spending all day savoring the clever hack you put in your code. I’m trying to fix a bug or add a feature. All the frippery just pulls me away from the problem at hand. There was an agile coach I heard an interview with who insisted that Tech Debt was the wrong analogy. He preferred Wear and Tear. I think the problems of kludgy or overclever code are more apparent if you think of it that way. At the very least, the main thoroughfares of the codebase need to be clean and free of dangerous obstacles.

refulgentis 8y ago

This is _so_ true. I have a unique career, no CS education, built a startup to scratch my itch, had no teammates on my codebase, worked on it for 5 years, sold it, now I've been at (insert FANG) for 2 years. On my own, I would look at code I wrote 6 months ago, wonder what idiot wrote that, then figure out if it was actually bad, or I just didn't understand it. With staff turnover and a lack of incentive for engineers to prioritize shipping (thats the manager and PM's problem), there's a heavy bias to "It's bad, rewrite it" rather than "Oh, it gets the job done, I just didn't understand it, let me research and comment the code". _Tons_ of time is wasted.

muzani 8y ago

If that's the case, it should be documented better. Not documented more though. Too often, people add too much documentation to the point nobody reads it. Instead of rewriting the code, there should be some effort to show figure out how it links and how it works together.

fnl 8y ago

Interesting that this reply is voted highest, as it doesn't actually answer the question, but rather suggest to ignore the entire issue.