4 ms·
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 n
by 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?