3 ms·

> A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows,

> A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows, and repair broken ones as you find them", but I'm finally at a point in my career where I can say, with confidence, that some broken windows aren't worth fixing; you might have enough expertise to know that it should be fixed, while simultaneously lacking the expertise to do so in a cost-effective way. Case in point: in the iOS app I'm currently working on for a client, my team discovered a bug that was, very clearly, an interest payment on the technical debt the client has been accruing. The "correct" bug fix would entail rewriting a lot of existing functionality (i.e. paying down a big chunk of the principal, on the technical debt). This was not cost effective for us, since we were being paid to fix the bug as written. So we fixed the bug, while introducing functionality that could, in the future, be used to pay down the tech debt principal, should the client desire to do so. Spoilers: the client will never desire to do so, and therefore we've actually just added cruft to the codebase. But this conclusion is not allowed, in the client-provider relationship; the bug is fixed, therefore contract conditions have been met, therefore the work is done. The cause of bad software is, simply, that the incentive structures and scheduling required for making good software don't usually exist.

mikepurvis 4y ago
> the bug is fixed, therefore contract conditions have been met, therefore the work is done Agile-type workflows also push toward this kind of prioritization— focus on story points, requested features, value delivered to the "customer", etc etc. It's obviously important, especially if the task at hand is to rein in a team consumed with grand rewrites and architecture astronaut stuff. But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt", but who engages meaningfully in understanding what the debt is, how it came about, and what the ongoing cost is of carrying it; and who can actually set milestones on the cleanup effort and communicate to the larger organization how it was valuable work to have done.
- andrekandre 4y ago
  > But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt" yep, if you are truly agile, you will be continuously improving the whole system you are working on otherwise it gets harder and slower to "deliver stories" to your customers... its a balance to be sure.
  - mikepurvis 4y ago
    Oh definitely, but that requires everyone to be on the same page about that, that every feature has a built in overhead of whatever% time allotted to general maintenance. Otherwise it's just a prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done than anyone else, as measured in story points.
    - andrekandre 4y ago
      > prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done i see this so often its not even funny anymore... (insert crying face here)

mikepurvis 4y ago

> the bug is fixed, therefore contract conditions have been met, therefore the work is done Agile-type workflows also push toward this kind of prioritization— focus on story points, requested features, value delivered to the "customer", etc etc. It's obviously important, especially if the task at hand is to rein in a team consumed with grand rewrites and architecture astronaut stuff. But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt", but who engages meaningfully in understanding what the debt is, how it came about, and what the ongoing cost is of carrying it; and who can actually set milestones on the cleanup effort and communicate to the larger organization how it was valuable work to have done.

andrekandre 4y ago
> But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt" yep, if you are truly agile, you will be continuously improving the whole system you are working on otherwise it gets harder and slower to "deliver stories" to your customers... its a balance to be sure.
- mikepurvis 4y ago
  Oh definitely, but that requires everyone to be on the same page about that, that every feature has a built in overhead of whatever% time allotted to general maintenance. Otherwise it's just a prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done than anyone else, as measured in story points.
  - andrekandre 4y ago
    > prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done i see this so often its not even funny anymore... (insert crying face here)