4 ms·

On technical debt, complexity and opportunity cost

18 points by anarchitect 13y ago

lifeisstillgood 13y ago
Philip Glass is for me the best writer on software development from a almost-academic-research point of view (#). In facts and fallacies He bangs on a lot about complexity (25% increase in code, 100% increase in complexity) and opportunity cost. Brooks touches on this in the mythical man month. What I am saying is that this is a good blog post, but this is stuff we should all know, all push to the PM and CEO with the morning mail, not have to be reminded of. Just if we have to relearn this every year, let alone every generation, what are we missing ? (#) really we have terrible software engineering research in the real world.
- rhubarbcustard 13y ago
  No wonder I had a hard time finding that Glass book in Google, it's Robert Glass, not Phillip. http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering-Robert/dp/0321117425 http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering...
  - lifeisstillgood 13y ago
    aargh - I keep doing that. Probably a dozen times over the past few years - it's the strangest thing. I now know more about a minimalist composers works than I ever expected to for a tone deaf Mozart fan.
- vermasque 13y ago
  "Just if we have to relearn this every year, let alone every generation" Perhaps this assumption is wrong. The problem is that some people never learned to be wary of the total cost of their choices. If you miss the forest for the trees, you'll never recognize the actions that can cause technical debt before the technical debt is realized.
mattip 13y ago
The hidden cost of early optimization can be hidden complexity and bugs. Take something slow and simple, replace with a cute trick that complicates and has corner cases and boom maintenance nightmare. In many cases while the optimization is obvious, it is unnecessary since no cold hard data on the cost of execution in production of the slow code actually exists
tenpoundhammer 13y ago
This has been a popular point lately. I wonder if it is a reflection of our current tool set around architecture and design. It seems realistic that implementing a "simple" new feature should not be inordinately costly, I don't dare to claim it should be a one to one relationship, but the current ratio seems out of control. I believe as the software industry increases it's understanding of architectural design that we will learn to add most types of features, in a systematically less costly way. Making them easier to maintain,update, and detangle from the rest of the software. In fact, I am finding that we are just now arriving at that point with functional languages. Not that functional is our savior, but it does provide a good set of tools for this particular problem. To wrap this up, I don't think software needs less code and less features. I think it needs better tools and methodologies with which to deal with creating, updating, and maintaining features and complexity.
- anarchitect 13y ago
  OP here, thanks for the comment. This topic is on my mind at the moment because I'm having to decide which features live and die as we migrate from a legacy platform to a new one. We're very keen to avoid unnecessary technical debt in that process, and to put better decision-making in place around new features as they are introduced.
  - lifeisstillgood 13y ago
    A gratuitous comment if you don't mind - I would try dropping the term legacy. It tends to set an existing system in concrete and creates a mindset of leaving it to pasture instead of actively refactoring and rewriting all the code existing and new, as architecture and sanity demand in short: rip a little functionality out of the existing code and refactor everything like mad to make it a sensible cut. I have found about As much effort goes into fixing up the existing code that just got damaged as writing the new.
    - anarchitect 13y ago
      Fair comment, but in this case the situation you describe is fairly accurate as it's a system that for various reasons my team don't have full control of.
michaelfeathers 13y ago
We don't understand the carrying cost of code yet in the industry. That's the problem.

18 points by anarchitect 13y ago

Philip Glass is for me the best writer on software development from a almost-academic-research point of view (#). In facts and fallacies He bangs on a lot about complexity (25% increase in code, 100% increase in complexity) and opportunity cost. Brooks touches on this in the mythical man month. What I am saying is that this is a good blog post, but this is stuff we should all know, all push to the PM and CEO with the morning mail, not have to be reminded of. Just if we have to relearn this every year, let alone every generation, what are we missing ? (#) really we have terrible software engineering research in the real world.

rhubarbcustard 13y ago
No wonder I had a hard time finding that Glass book in Google, it's Robert Glass, not Phillip. http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering-Robert/dp/0321117425 http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering...
- lifeisstillgood 13y ago
  aargh - I keep doing that. Probably a dozen times over the past few years - it's the strangest thing. I now know more about a minimalist composers works than I ever expected to for a tone deaf Mozart fan.
vermasque 13y ago
"Just if we have to relearn this every year, let alone every generation" Perhaps this assumption is wrong. The problem is that some people never learned to be wary of the total cost of their choices. If you miss the forest for the trees, you'll never recognize the actions that can cause technical debt before the technical debt is realized.

mattip 13y ago

The hidden cost of early optimization can be hidden complexity and bugs. Take something slow and simple, replace with a cute trick that complicates and has corner cases and boom maintenance nightmare. In many cases while the optimization is obvious, it is unnecessary since no cold hard data on the cost of execution in production of the slow code actually exists

tenpoundhammer 13y ago

This has been a popular point lately. I wonder if it is a reflection of our current tool set around architecture and design. It seems realistic that implementing a "simple" new feature should not be inordinately costly, I don't dare to claim it should be a one to one relationship, but the current ratio seems out of control. I believe as the software industry increases it's understanding of architectural design that we will learn to add most types of features, in a systematically less costly way. Making them easier to maintain,update, and detangle from the rest of the software. In fact, I am finding that we are just now arriving at that point with functional languages. Not that functional is our savior, but it does provide a good set of tools for this particular problem. To wrap this up, I don't think software needs less code and less features. I think it needs better tools and methodologies with which to deal with creating, updating, and maintaining features and complexity.

anarchitect 13y ago
OP here, thanks for the comment. This topic is on my mind at the moment because I'm having to decide which features live and die as we migrate from a legacy platform to a new one. We're very keen to avoid unnecessary technical debt in that process, and to put better decision-making in place around new features as they are introduced.
- lifeisstillgood 13y ago
  A gratuitous comment if you don't mind - I would try dropping the term legacy. It tends to set an existing system in concrete and creates a mindset of leaving it to pasture instead of actively refactoring and rewriting all the code existing and new, as architecture and sanity demand in short: rip a little functionality out of the existing code and refactor everything like mad to make it a sensible cut. I have found about As much effort goes into fixing up the existing code that just got damaged as writing the new.
  - anarchitect 13y ago
    Fair comment, but in this case the situation you describe is fairly accurate as it's a system that for various reasons my team don't have full control of.

michaelfeathers 13y ago

We don't understand the carrying cost of code yet in the industry. That's the problem.