6 ms·

Managing technical debt is one of them most important parts of engineering. When you're resource constrained, which is almost a given in the real world, you nee

Managing technical debt is one of them most important parts of engineering. When you're resource constrained, which is almost a given in the real world, you need to think carefully about what kinds of debts are worth accruing, and what kinds are absolutely not. I think this is both an art and a science, and the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture. There are so many factors involved that it's not surprising so many projects accrue horrible debt.

raverbashing 9y ago
Also, some debts are not even debts, but normal limitations of the code If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt
- Cthulhu_ 9y ago
  It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.
  - beersigns 9y ago
    Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.
    - aldanor 9y ago
      Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).
- cryptonector 9y ago
  Sort of. You could have used better techniques/frameworks/whatever and gotten it right from the get-go. It does help to have the experience to intuit/know what you'll have to make scale and to what degree so that you can spend cycles on avoiding likely pitfalls without wasting too much effort.
  - raverbashing 9y ago
    I would be a very rich person if I got a dollar for every time the "right framework/solution/technique" broke unexpectedly when pushing it in certain ways. Or it might not even have existed (or was unstable) when you started work, but it got better later.
    - cryptonector 9y ago
      I was thinking of things like: thread-per-client vs C10K. Just go C10K all the way. That means write services to be async, async, async. Just do it. It will not be the case that thread-per-client is better than C10K except when you know you'll only have a handful of clients. Write code to be thread-safe / reentrant. Write code to be separable into libraries. I'd also urge you to use higher-level languages from the get-go. If you can use Rust instead of C, do it. If Haskell is appropriate, use it. These are all choices that are fantastically easier to make early on than later.
      - mpfundstein 9y ago
        Yes. Some things are just obvious easy wins. And still I am surprised how often we choose to do differenT. Its the same readon why I almost always immediately use vue or react. Because it doesnt cost me much (~0) but if that thing has to scale i’ll be ready
  - eanzenberg 9y ago
    I think that's the point. You choose the best tech at the moment given the requirements with some headroom. Why waste engineering time to make sure it is hardened to support 10x load? Sometimes it is easy (use a different library) but most of the time it is hard.
- IncRnd 9y ago
  Technical debt is the cost of reworking software not the features or existence of the software.
thisisit 9y ago
> the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture. I couldn't have stated it better myself. Most of the time it start from culture, leadership and then experience etc. I have worked on multiple projects with varied amount of technical debt. But the project with the most amount of debt happened because of poor leadership. The guy who was managing the project was more interested in currying favor. The end result - everyone's salary was being shared across the company in un-encrypted plain text format.
- internetman55 9y ago
  A manager I worked with previously was like that--no interest in making sure the project could be maintained or actually worked, only promising things to people who didn't even use our platform (me and a coworker checked our logs before I left the company) and getting "wins" so he could talk about them in meetings.
  - TheOtherHobbes 9y ago
    That's organisational debt, which is a prime cause of technical debt. It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes.
    - dragonwriter 9y ago
      > It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes. Does it? The manager in GP, for instance, seems to be a textbook example of a thermocline of truth.
    - 52-6F-62 9y ago
      It actually reminds me of regular corporate life in a confused company— and in turn, this: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
peterwwillis 9y ago
Are you talking about software engineering, or engineering engineering? Because I don't think building engineers create technical debt.
- wskinner 9y ago
  Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. That flexibility means that the first release need not be the last release. The obvious charitable interpretation is that the parent was talking about software.
  - tarmstrong 9y ago
    > Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building. I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless. If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering. (This is not a field I'm familiar with so any errors are mine, not my friend's.)
- pjc50 9y ago
  Buildings can definitely accumulate technical debt when they're put through a series of changes of use over time. It manifests as odd cable routing, inconsistent floor levels, repeatedly moved doorways, obstructed windows, etc.

raverbashing 9y ago

Also, some debts are not even debts, but normal limitations of the code If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt

Cthulhu_ 9y ago
It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.
- beersigns 9y ago
  Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.
  - aldanor 9y ago
    Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).
cryptonector 9y ago
Sort of. You could have used better techniques/frameworks/whatever and gotten it right from the get-go. It does help to have the experience to intuit/know what you'll have to make scale and to what degree so that you can spend cycles on avoiding likely pitfalls without wasting too much effort.
- raverbashing 9y ago
  I would be a very rich person if I got a dollar for every time the "right framework/solution/technique" broke unexpectedly when pushing it in certain ways. Or it might not even have existed (or was unstable) when you started work, but it got better later.
  - cryptonector 9y ago
    I was thinking of things like: thread-per-client vs C10K. Just go C10K all the way. That means write services to be async, async, async. Just do it. It will not be the case that thread-per-client is better than C10K except when you know you'll only have a handful of clients. Write code to be thread-safe / reentrant. Write code to be separable into libraries. I'd also urge you to use higher-level languages from the get-go. If you can use Rust instead of C, do it. If Haskell is appropriate, use it. These are all choices that are fantastically easier to make early on than later.
    - mpfundstein 9y ago
      Yes. Some things are just obvious easy wins. And still I am surprised how often we choose to do differenT. Its the same readon why I almost always immediately use vue or react. Because it doesnt cost me much (~0) but if that thing has to scale i’ll be ready
- eanzenberg 9y ago
  I think that's the point. You choose the best tech at the moment given the requirements with some headroom. Why waste engineering time to make sure it is hardened to support 10x load? Sometimes it is easy (use a different library) but most of the time it is hard.
IncRnd 9y ago
Technical debt is the cost of reworking software not the features or existence of the software.

thisisit 9y ago

> the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture. I couldn't have stated it better myself. Most of the time it start from culture, leadership and then experience etc. I have worked on multiple projects with varied amount of technical debt. But the project with the most amount of debt happened because of poor leadership. The guy who was managing the project was more interested in currying favor. The end result - everyone's salary was being shared across the company in un-encrypted plain text format.

internetman55 9y ago
A manager I worked with previously was like that--no interest in making sure the project could be maintained or actually worked, only promising things to people who didn't even use our platform (me and a coworker checked our logs before I left the company) and getting "wins" so he could talk about them in meetings.
- TheOtherHobbes 9y ago
  That's organisational debt, which is a prime cause of technical debt. It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes.
  - dragonwriter 9y ago
    > It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes. Does it? The manager in GP, for instance, seems to be a textbook example of a thermocline of truth.
  - 52-6F-62 9y ago
    It actually reminds me of regular corporate life in a confused company— and in turn, this: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

peterwwillis 9y ago

Are you talking about software engineering, or engineering engineering? Because I don't think building engineers create technical debt.

wskinner 9y ago
Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. That flexibility means that the first release need not be the last release. The obvious charitable interpretation is that the parent was talking about software.
- tarmstrong 9y ago
  > Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building. I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless. If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering. (This is not a field I'm familiar with so any errors are mine, not my friend's.)
pjc50 9y ago
Buildings can definitely accumulate technical debt when they're put through a series of changes of use over time. It manifests as odd cable routing, inconsistent floor levels, repeatedly moved doorways, obstructed windows, etc.