3 ms·

Its not tech debt. Its rigidity and fragility. If you only add features, you gain rigidity and fragility. To go fast you must go well. Teams that balance m

Its not tech debt. Its rigidity and fragility. If you only add features, you gain rigidity and fragility. To go fast you must go well. Teams that balance maintainability against features have a competitive advantage and will beat you every time. Going "fast" immediately slows you down. Right then and there. You think you're going fast but you're just fooling yourself. The DevOps Handbook goes into this - you need to spend 20% of the teams time on clean code and maintainability.

xwolfi 4y ago
Not 19, not 21, 20. That's how you remove rigidity? Most places who apply handbooks end up applying handbooks to the detriments of everything else. I feel we need to embrace the fact software is a fluid monster and we must work at it dynamically: cleaning up when it s unbearably crappy, adding to it when clients and users depend on it, and a balance between both when clients can wait a bit or when the dirt hasn't settled yet. Then you d have a team that delivers rather than state that we must lose the client because his need overlap our 20% "moving classes around more logical namespaces" clean code.
- mike_hock 4y ago
  > Not 19, not 21, 20. That's how you remove rigidity? I mean, the fact that the 20% figure is only a rough guideline is so obvious it doesn't need to be stated.
- Cpoll 4y ago
  > Then you d have a team that delivers rather than state that we must lose the client because his need overlap our 20% "moving classes around more logical namespaces" clean code. Which sounds like something that happened zero times ever. The problem is rarely that there's too much tech debt work, it's that client requirements take over dev work right up until the product goes up in flames (at which point the client you meticulously built features for disappears along with the rest). Since you're rejecting handbooks, how do you define "unbearably crappy?" Perhaps it's when the devs have already started looking for new jobs? And then, if it's unbearably crappy and you start cleaning up and a client comes with requirements, do you drop the cleanup work?

xwolfi 4y ago

Not 19, not 21, 20. That's how you remove rigidity? Most places who apply handbooks end up applying handbooks to the detriments of everything else. I feel we need to embrace the fact software is a fluid monster and we must work at it dynamically: cleaning up when it s unbearably crappy, adding to it when clients and users depend on it, and a balance between both when clients can wait a bit or when the dirt hasn't settled yet. Then you d have a team that delivers rather than state that we must lose the client because his need overlap our 20% "moving classes around more logical namespaces" clean code.

mike_hock 4y ago
> Not 19, not 21, 20. That's how you remove rigidity? I mean, the fact that the 20% figure is only a rough guideline is so obvious it doesn't need to be stated.
Cpoll 4y ago
> Then you d have a team that delivers rather than state that we must lose the client because his need overlap our 20% "moving classes around more logical namespaces" clean code. Which sounds like something that happened zero times ever. The problem is rarely that there's too much tech debt work, it's that client requirements take over dev work right up until the product goes up in flames (at which point the client you meticulously built features for disappears along with the rest). Since you're rejecting handbooks, how do you define "unbearably crappy?" Perhaps it's when the devs have already started looking for new jobs? And then, if it's unbearably crappy and you start cleaning up and a client comes with requirements, do you drop the cleanup work?