9 ms·

Beautiful Technical Debt

65 points by fagnerbrack 5y ago

goldenkey 5y ago
There's beauty in a turd if it's polished and looked at through rose-tinted lenses. It's still not the type of beauty that I'd like to marry myself to.
- webmaven 5y ago
  Not turds per-se, but there is a whole art form dedicated to polishing mud: https://en.m.wikipedia.org/wiki/Dorodango https://en.m.wikipedia.org/wiki/Dorodango
  - muzani 5y ago
    Actual turd polishing using that technique: https://youtube.com/watch?v=yiJ9fy1qSFI https://youtube.com/watch?v=yiJ9fy1qSFI
hinkley 5y ago
The shitty code you wrote two years ago to retain a customer may have needed to be written, but that’s absolutely no excuse for keeping it now. Those are two different scenarios and you can’t defend one with the other. Stop apologizing for your old code and just fix it.
- Juliate 5y ago
  Unless, for one instance possibility, among others, unless that « shitty » part is actual uncovered crucial behavior your team didn’t think of, that might present itself again, and even reveal a profitable new perspective on the market you’re trying to build on. If only in teaching new comers of a potential (apparently) edge case.
vaylian 5y ago
> Don't just try to pay the technical debt off, but embrace and dig beneath. Dig into the problems , conduct customer interviews with stakeholders, get more data, and validate solutions early. Good luck with that. This won't work in most situations, because the people involved have moved on or are too busy to talk to you about something that will only benefit you, but not them. Most non-software engineers won't understand the argument of development velocity in the context of technical debt. The thing that makes technical debt so miserable is that you are usually lacking context. Code comments can make a huge difference here. If a developer has to cut corners, the reason for the bad code has to be documented. Otherwise it is hard to judge if the code just looks bad but is actually fairly optimal, or if it is actually bad and a rewrite is encouraged.
- Juliate 5y ago
  > Most non-software engineers won't understand the argument of development velocity in the context of technical debt. (Public) building engineers, carpenters, archeologists, architects (that is, anyone that has a long time scale understanding, before and after their work) have certainly a good understanding of what "velocity" is and how it would be impacted by their options of intervention on a specific project for later interventions (and how it is today impacted by the choices of those that came before). They don't call this technical debt for that matter.
ge96 5y ago
Ahh does suck when you start with a clean slate everything looks nice then quickly starts to turn into crap... But yeah speed is nice cramming two weeks of work into 20hrs.
dgb23 5y ago
I like this. Thoughts like these emerge from detachment and playful curiosity. There’s a related thing: Hacks, workarounds and quick and dirty fixes have to go somewhere, because they happen anyway. It’s better to have space for them, then to mix them with organized code. Now you have a place (or other convention) for inconsistency and scarred code. It’s more honest, obvious and easier to fix.
hooby 5y ago
The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. With software you can avoid the "pay it back" part - simply by retiring the software entirely. But you cannot avoid the interest - as long as you keep maintaining and supporting the software, the debt present within, will cause extra work and extra pain. That recurring interest can accumulate to the point, where it's more expensive to pay the interest, than it would be to just throw everything away and start from scratch. But you can't retire the old code before the new code is ready to replace it - and you don't have the capacity to write the new code while all your effort goes into maintaining the old code. Your existing developers increasingly burn out on maintaining the old code, some might even quit, and you are unable to hire new developers, since they'd rather sign up for another company that isn't that deep into legacy problems. This is the dead end you want to avoid - and the best way to avoid it, is to get rid of any technical debt as soon as possible. It's okay to make the strategic decision to take shortcuts in order to meet a deadline or keep a customer - but letting the resulting debt accumulate is not sustainable in the long run.
- repomies69 5y ago
  > The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. Bullshit. Typical startup fails. So, typically all the investments to reduce future technical debt is waste. Engineering teams make often a huge issue about technical debt, sometimes in companies where it looks pretty clear that there is no much use in removing that technical debt since future investments in the company/technology seem unlikely. I guess in these situations the problem is that the leadership is not really eager to communicate the real situation to the devs.
  - oaiey 5y ago
    But not everything is a startup. Quite the opposite actually. I agree with your second point, finished products/companies are finished. No reason to pay debt there if the pure maintenance (if any) is not impacted. But as with the other topic: That is often not the case.
  - parksy 5y ago
altacc 5y ago
This is quite a simple interpretation and so going to be wrong in many situations. But I find that so are those who are adamant that all technical debt is bad. I've seen some people fixate on the idea of technical debt and tie themselves in knots with the impossible mission of not creating any. I see technical debt as akin to government debt, in that some amount enables flexibility and agility so can be accepted and handled but too much debt can rapidly become crippling, especially at times of crisis or bug change. So thoughtful design choices are needed about when to accept some debt, when to do more work to not introduce any, and very importantly, when to pay some off.
- hgomersall 5y ago
  It's nothing like government debt denominated in the sovereign currency, which is never crippling.
mro_name 5y ago
> There is a beauty in that, if observed from a distance. lol. Like every other mess.
oaiey 5y ago
There is nothing beautiful of technical debt. I see only pain and problems when I see a technical debt. Not that these need to be fixed/cleaned/paid or do not teach us a lesson, but let us agree on not calling it beautiful.
fn1 5y ago
We should stop calling it "technical debt". That word suggests a clean account that can be paid off from time to time. Instead let's call it "technical clutter", because that is what it is. It's the equivalent of an unclean workshop with broken and unused tools lying around. You trip over everything, you cannot find anything, your tools hurt you or slow you down. Managers need to understand that technical clutter is central in hindering and slowing development. Not a separate account that is not affecting work.
- louthy 5y ago
  > You trip over everything, you cannot find anything, your tools hurt you or slow you down. This is the interest you pay. 'Debt' captures the problem of it being an ongoing cost.
- Aeolun 5y ago
  I think the important analog for the debt part is that it accumulates over time. At some point you are only paying off your technical debt, instead of building new features. At that point your project is bankrupt.
- DocTomoe 5y ago
  Ultimately, your suggestion is problematic - it moves culpability for technical debt/clutter from management/customers to the developers. With "technical debt" you could argue that business demands coming down to "I want it NOW" will lead to slower or more work later, and give management agency in determining if that is in line with the value they expect to gain. With "technical clutter", the problem is moved to the devs: They could just have, you know, "worked cleaner" to begin with (nevermind we never gave them the time to do so). It's their own mess that originated by their decision, not the mess caused by PMs or customer expectations. And if the mess caused by mess-inducing management tactics becomes too big, management would just fire "bad" devs and hire some newbies. So ... I do get where you're coming from. With normal people, the difference in meaning would lead to better understanding. But management has a large amount of non-normal folks.
  - Juliate 5y ago
paskozdilar 5y ago
IMHO, the most important thing is to remember what is your goal in the first place. It is way too easy for an engineer to lose himself in the microsphere of his project, wanting to make better software for the sake of better software. That often clashes with the goal of the organization - the only relevant result is whether the software works or not (or, in the case of most non-critical applications, what percentage of software works). The downside is that technical debt can massively increase development time - and there is no way to measure how much time you're losing because, to know that, you would have to be free of technical debt in the exact same scenario.
readme 5y ago
if as a software engineer, you prefer to live a life where you wake up to absurd work daily, each day fixing a bug in a way that creates two more, or introducing a feature that creates three more, sure, technical debt is beautiful
andrewingram 5y ago
The analogy of the pine tree is an interesting one, it identifies that the shape of a technical product is not just about what problems it needs to solve today, but also the history of problems it's had to solve to get to today. What the post fails to call out is that many of those problems simply might not exist anymore. That tree may have had to weather a freak once-in-a-thousand-years stormy season, and has structural baggage as a result; but if that tree were to grow again starting today, a repeat season may never happen and the tree would end up looking different. One way we can consider technical debt is the extent to which the current solution differs from an (often mythical or at least hypothetical) ideal solution. How different would it look if we built it today, with only today's constraints, rather than all the historical ones? How much is that historical baggage getting in the way of us moving forwards?
- louwrentius 5y ago
  I still don’t see a benefit of being vague and call this TD. You can be explicit and explain why things are as they are and if we have to do some extra work because of code addressing no-longer-relevant-use-cases, that’s just it. No need to call this TD. Be clear and explicit. I think in most cases, Technical Debt is a much abused term to bullshit and cover up past mistakes. TD sounds much better than mistake and it sounds so ‘inevitable’, so you can’t be blamed.
  - andrewingram 5y ago
    I don't disagree, I have no real attachment to the term and I think there's too much nitpicking about what the precise definition is. At the end of the day, sometimes past work can slow down present and future work; and if the impact is significant, you should do something about it.
whoomp12342 5y ago
oh, I embrace the technical debt. I embrace it when it slows down my productivity and puts stress lumps in my shoulder

65 points by fagnerbrack 5y ago

There's beauty in a turd if it's polished and looked at through rose-tinted lenses. It's still not the type of beauty that I'd like to marry myself to.

webmaven 5y ago
Not turds per-se, but there is a whole art form dedicated to polishing mud: https://en.m.wikipedia.org/wiki/Dorodango https://en.m.wikipedia.org/wiki/Dorodango
- muzani 5y ago
  Actual turd polishing using that technique: https://youtube.com/watch?v=yiJ9fy1qSFI https://youtube.com/watch?v=yiJ9fy1qSFI

hinkley 5y ago

The shitty code you wrote two years ago to retain a customer may have needed to be written, but that’s absolutely no excuse for keeping it now. Those are two different scenarios and you can’t defend one with the other. Stop apologizing for your old code and just fix it.

Juliate 5y ago
Unless, for one instance possibility, among others, unless that « shitty » part is actual uncovered crucial behavior your team didn’t think of, that might present itself again, and even reveal a profitable new perspective on the market you’re trying to build on. If only in teaching new comers of a potential (apparently) edge case.

vaylian 5y ago

> Don't just try to pay the technical debt off, but embrace and dig beneath. Dig into the problems , conduct customer interviews with stakeholders, get more data, and validate solutions early. Good luck with that. This won't work in most situations, because the people involved have moved on or are too busy to talk to you about something that will only benefit you, but not them. Most non-software engineers won't understand the argument of development velocity in the context of technical debt. The thing that makes technical debt so miserable is that you are usually lacking context. Code comments can make a huge difference here. If a developer has to cut corners, the reason for the bad code has to be documented. Otherwise it is hard to judge if the code just looks bad but is actually fairly optimal, or if it is actually bad and a rewrite is encouraged.

Juliate 5y ago
> Most non-software engineers won't understand the argument of development velocity in the context of technical debt. (Public) building engineers, carpenters, archeologists, architects (that is, anyone that has a long time scale understanding, before and after their work) have certainly a good understanding of what "velocity" is and how it would be impacted by their options of intervention on a specific project for later interventions (and how it is today impacted by the choices of those that came before). They don't call this technical debt for that matter.

ge96 5y ago

Ahh does suck when you start with a clean slate everything looks nice then quickly starts to turn into crap... But yeah speed is nice cramming two weeks of work into 20hrs.

dgb23 5y ago

I like this. Thoughts like these emerge from detachment and playful curiosity. There’s a related thing: Hacks, workarounds and quick and dirty fixes have to go somewhere, because they happen anyway. It’s better to have space for them, then to mix them with organized code. Now you have a place (or other convention) for inconsistency and scarred code. It’s more honest, obvious and easier to fix.

hooby 5y ago

The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. With software you can avoid the "pay it back" part - simply by retiring the software entirely. But you cannot avoid the interest - as long as you keep maintaining and supporting the software, the debt present within, will cause extra work and extra pain. That recurring interest can accumulate to the point, where it's more expensive to pay the interest, than it would be to just throw everything away and start from scratch. But you can't retire the old code before the new code is ready to replace it - and you don't have the capacity to write the new code while all your effort goes into maintaining the old code. Your existing developers increasingly burn out on maintaining the old code, some might even quit, and you are unable to hire new developers, since they'd rather sign up for another company that isn't that deep into legacy problems. This is the dead end you want to avoid - and the best way to avoid it, is to get rid of any technical debt as soon as possible. It's okay to make the strategic decision to take shortcuts in order to meet a deadline or keep a customer - but letting the resulting debt accumulate is not sustainable in the long run.

repomies69 5y ago
> The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. Bullshit. Typical startup fails. So, typically all the investments to reduce future technical debt is waste. Engineering teams make often a huge issue about technical debt, sometimes in companies where it looks pretty clear that there is no much use in removing that technical debt since future investments in the company/technology seem unlikely. I guess in these situations the problem is that the leadership is not really eager to communicate the real situation to the devs.
- oaiey 5y ago
  But not everything is a startup. Quite the opposite actually. I agree with your second point, finished products/companies are finished. No reason to pay debt there if the pure maintenance (if any) is not impacted. But as with the other topic: That is often not the case.
- parksy 5y ago

altacc 5y ago

This is quite a simple interpretation and so going to be wrong in many situations. But I find that so are those who are adamant that all technical debt is bad. I've seen some people fixate on the idea of technical debt and tie themselves in knots with the impossible mission of not creating any. I see technical debt as akin to government debt, in that some amount enables flexibility and agility so can be accepted and handled but too much debt can rapidly become crippling, especially at times of crisis or bug change. So thoughtful design choices are needed about when to accept some debt, when to do more work to not introduce any, and very importantly, when to pay some off.

hgomersall 5y ago
It's nothing like government debt denominated in the sovereign currency, which is never crippling.

mro_name 5y ago

> There is a beauty in that, if observed from a distance. lol. Like every other mess.

oaiey 5y ago

There is nothing beautiful of technical debt. I see only pain and problems when I see a technical debt. Not that these need to be fixed/cleaned/paid or do not teach us a lesson, but let us agree on not calling it beautiful.

fn1 5y ago

We should stop calling it "technical debt". That word suggests a clean account that can be paid off from time to time. Instead let's call it "technical clutter", because that is what it is. It's the equivalent of an unclean workshop with broken and unused tools lying around. You trip over everything, you cannot find anything, your tools hurt you or slow you down. Managers need to understand that technical clutter is central in hindering and slowing development. Not a separate account that is not affecting work.

louthy 5y ago
> You trip over everything, you cannot find anything, your tools hurt you or slow you down. This is the interest you pay. 'Debt' captures the problem of it being an ongoing cost.
Aeolun 5y ago
I think the important analog for the debt part is that it accumulates over time. At some point you are only paying off your technical debt, instead of building new features. At that point your project is bankrupt.
DocTomoe 5y ago
Ultimately, your suggestion is problematic - it moves culpability for technical debt/clutter from management/customers to the developers. With "technical debt" you could argue that business demands coming down to "I want it NOW" will lead to slower or more work later, and give management agency in determining if that is in line with the value they expect to gain. With "technical clutter", the problem is moved to the devs: They could just have, you know, "worked cleaner" to begin with (nevermind we never gave them the time to do so). It's their own mess that originated by their decision, not the mess caused by PMs or customer expectations. And if the mess caused by mess-inducing management tactics becomes too big, management would just fire "bad" devs and hire some newbies. So ... I do get where you're coming from. With normal people, the difference in meaning would lead to better understanding. But management has a large amount of non-normal folks.
- Juliate 5y ago

paskozdilar 5y ago

IMHO, the most important thing is to remember what is your goal in the first place. It is way too easy for an engineer to lose himself in the microsphere of his project, wanting to make better software for the sake of better software. That often clashes with the goal of the organization - the only relevant result is whether the software works or not (or, in the case of most non-critical applications, what percentage of software works). The downside is that technical debt can massively increase development time - and there is no way to measure how much time you're losing because, to know that, you would have to be free of technical debt in the exact same scenario.

readme 5y ago

if as a software engineer, you prefer to live a life where you wake up to absurd work daily, each day fixing a bug in a way that creates two more, or introducing a feature that creates three more, sure, technical debt is beautiful

andrewingram 5y ago

The analogy of the pine tree is an interesting one, it identifies that the shape of a technical product is not just about what problems it needs to solve today, but also the history of problems it's had to solve to get to today. What the post fails to call out is that many of those problems simply might not exist anymore. That tree may have had to weather a freak once-in-a-thousand-years stormy season, and has structural baggage as a result; but if that tree were to grow again starting today, a repeat season may never happen and the tree would end up looking different. One way we can consider technical debt is the extent to which the current solution differs from an (often mythical or at least hypothetical) ideal solution. How different would it look if we built it today, with only today's constraints, rather than all the historical ones? How much is that historical baggage getting in the way of us moving forwards?

louwrentius 5y ago
I still don’t see a benefit of being vague and call this TD. You can be explicit and explain why things are as they are and if we have to do some extra work because of code addressing no-longer-relevant-use-cases, that’s just it. No need to call this TD. Be clear and explicit. I think in most cases, Technical Debt is a much abused term to bullshit and cover up past mistakes. TD sounds much better than mistake and it sounds so ‘inevitable’, so you can’t be blamed.
- andrewingram 5y ago
  I don't disagree, I have no real attachment to the term and I think there's too much nitpicking about what the precise definition is. At the end of the day, sometimes past work can slow down present and future work; and if the impact is significant, you should do something about it.

whoomp12342 5y ago

oh, I embrace the technical debt. I embrace it when it slows down my productivity and puts stress lumps in my shoulder