5 ms·

Agree. It's just tradeoffs. Some projects don't warrant over engineering because the requirements are often not clear in the beginning. There's a cost in terms

Agree. It's just tradeoffs. Some projects don't warrant over engineering because the requirements are often not clear in the beginning. There's a cost in terms of resources and opportunity which often doesn't make sense to incur at an earlier stage of product development. As the first few versions play out in the market, the requirements are better understood, the product starts fitting the market better. Obviously, a lot of the earlier choices don't seem optimal for what the product becomes at a later time. Yes, theoretically, "it could have been done better", but nobody could have known for sure. It should simply be refactored so that the design of the software better fits what it is doing at a given time... and this should be an expected way to develop products. I think "technical debt" is often the wrong term for what is going on. I'm sure there is a better analogy in terms of business and finance to what is happening... but I'm not well-versed in finance to say what it is.

tonystubblebine 6y ago
> wrong term for what's going on. Exactly. It's such a loaded term and it can almost always be replaced by saying something specific.
- cutemonster 6y ago
  I didn't know it can be a loaded term (for some people). What are some things to say instead? "Past mistakes" maybe? In some cases
dhsysusbsjsi 6y ago
Agree - I came here to say the same thing. Most engineers have an eye for quality and maintainability which is great, however what they sometimes fail to see is that in a commercial reality, rapidly iterating on features to be first mover advantage is "worth" the piles of dirty dishes incurred, even if it's a huge headache later on maintaining it. Often it's an existential threat - you either move fast (and often do the 95% solution to ship) or you are gone. I find quite often engineers without the big picture/reality of the business can often forget that everything is an engineering tradeoff and maybe copy+paste and a bit of spaghetti is your friend today because your firm just expanded. All of the previous analogies about libraries and dishes need an added layer: if they shut down for a week at the start to re-organise and clean, perhaps they would have gone bankrupt and the stupid solution may have actually been the best one all along.
- pseudalopex 6y ago
  Most engineers can tell the difference between things they wish were better and things constantly in the way of things the business wants.
different_sort 6y ago
I work in an huge enterprise. We have incredibly customized software and stacks that have not changed much for 30 years, because they did not need to. Now the people who wrote those stacks and who understand them are retiring/quitting. Kids coming out of school don't want to learn these systems, nor do people off the streets. You can only pay people to come out of retirement so many times to keep the plant running. This is above and beyond mainframes, and is intertwined deep in the code that powers every single application that runs the plant today. We can't run off the shelf software on-prem, a huge level of customization is needed to bring it in. We cannot pivot quickly to new things or support new languages. We really struggle to add new features/releases and add new software to drive revenue. The IT overhead that just goes into keeping the plant running every day is astounding. This is what I think of when I hear technical debt. Going down this road did give us advantages for a long time, but now we're in an enormous crisis. It's not an insurmountable challenge, but I would be surprised if there aren't a lot of large companies who are brought down by their technical debt as faster moving competitors move around them. I certainly feel that unless we get our act together, we will be disrupted.
- sago 6y ago
  I found this response surprising. Code that has worked for 30 years is more technical debt than the ability to support 'new languages' or 'pivot' the code? Maybe I am an old fart, but the opposite seems right to me. Large code bases are difficult to add functionality to. A code base that is easy to pivot and switch languages sounds more like a nightmare. Isn't it more likely that your new, zeitgeist-capable software would torpedo development in far less than 30 years. As I understand "new programmers", the 'reinventing the wheel' speed is measured in a few years not decades now. Or did I misunderstand you?
  - different_sort 6y ago
    I think it represented poorly. It's more than just code in one system. It's systems built upon systems built upon systems. It encompasses our network, our software deployment stack, our proprietary extensions to standards and much much more. Unknown dependencies on unknown dependencies on unknown dependencies (and it's not like we're slacking on trying to map that/keep the asset inventory up to date). It's basically paralyzing. It's so hard to get a release done, add capacity, or add new features for our lines of business (we have dozens!).

tonystubblebine 6y ago

> wrong term for what's going on. Exactly. It's such a loaded term and it can almost always be replaced by saying something specific.

cutemonster 6y ago
I didn't know it can be a loaded term (for some people). What are some things to say instead? "Past mistakes" maybe? In some cases

dhsysusbsjsi 6y ago

Agree - I came here to say the same thing. Most engineers have an eye for quality and maintainability which is great, however what they sometimes fail to see is that in a commercial reality, rapidly iterating on features to be first mover advantage is "worth" the piles of dirty dishes incurred, even if it's a huge headache later on maintaining it. Often it's an existential threat - you either move fast (and often do the 95% solution to ship) or you are gone. I find quite often engineers without the big picture/reality of the business can often forget that everything is an engineering tradeoff and maybe copy+paste and a bit of spaghetti is your friend today because your firm just expanded. All of the previous analogies about libraries and dishes need an added layer: if they shut down for a week at the start to re-organise and clean, perhaps they would have gone bankrupt and the stupid solution may have actually been the best one all along.

pseudalopex 6y ago
Most engineers can tell the difference between things they wish were better and things constantly in the way of things the business wants.

different_sort 6y ago

I work in an huge enterprise. We have incredibly customized software and stacks that have not changed much for 30 years, because they did not need to. Now the people who wrote those stacks and who understand them are retiring/quitting. Kids coming out of school don't want to learn these systems, nor do people off the streets. You can only pay people to come out of retirement so many times to keep the plant running. This is above and beyond mainframes, and is intertwined deep in the code that powers every single application that runs the plant today. We can't run off the shelf software on-prem, a huge level of customization is needed to bring it in. We cannot pivot quickly to new things or support new languages. We really struggle to add new features/releases and add new software to drive revenue. The IT overhead that just goes into keeping the plant running every day is astounding. This is what I think of when I hear technical debt. Going down this road did give us advantages for a long time, but now we're in an enormous crisis. It's not an insurmountable challenge, but I would be surprised if there aren't a lot of large companies who are brought down by their technical debt as faster moving competitors move around them. I certainly feel that unless we get our act together, we will be disrupted.

sago 6y ago
I found this response surprising. Code that has worked for 30 years is more technical debt than the ability to support 'new languages' or 'pivot' the code? Maybe I am an old fart, but the opposite seems right to me. Large code bases are difficult to add functionality to. A code base that is easy to pivot and switch languages sounds more like a nightmare. Isn't it more likely that your new, zeitgeist-capable software would torpedo development in far less than 30 years. As I understand "new programmers", the 'reinventing the wheel' speed is measured in a few years not decades now. Or did I misunderstand you?
- different_sort 6y ago
  I think it represented poorly. It's more than just code in one system. It's systems built upon systems built upon systems. It encompasses our network, our software deployment stack, our proprietary extensions to standards and much much more. Unknown dependencies on unknown dependencies on unknown dependencies (and it's not like we're slacking on trying to map that/keep the asset inventory up to date). It's basically paralyzing. It's so hard to get a release done, add capacity, or add new features for our lines of business (we have dozens!).