5 ms·

Scrum has been a catastrophe to the software industry (argued elsewhere countless times) - I don't want to imagine the consequences it can have for jet figthers

by vemv 7y ago

Scrum has been a catastrophe to the software industry (argued elsewhere countless times) - I don't want to imagine the consequences it can have for jet figthers. For such environments you definitely want to have no deadlines at all, to have a special focus on well-defined requirements, and in software quality. That investment should be marginal compared to hardware costs. And in fact, by going more slowly, you end up delivering faster after a couple years, when you enjoy zero tech debt and an excellent foundation.

smileysteve 7y ago
> when you enjoy zero tech debt and an excellent foundation. This implies that you plan exactly when and where tech debt is accumulating or found. The scrum argument is that by iterating and releasing, you find out where unexpected tech debt is more rapidly; and you go back and fix it. One way that #AgileIsDead happens is when products disregard the tech debt for features even as it becomes apparent.
- vemv 7y ago
  Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. (I'm open to be convinced) Generally I have witnessed tech debt as something pretty blatant and obvious - generally it's detected in the code review process. Sometimes it's big faults being introduced, more often it's small faults leading to 'death by a thousand cuts'. My current policy is to allow zero tech debt, following the "no broken windows" principle. https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy https://pragprog.com/the-pragmatic-programmer/extracts/softw... That involves a greater investment in code reviews.
  - ergothus 7y ago
    > My current policy is to allow zero tech debt I was in an office that had such a policy - it didn't go well. Perhaps it's a matter of definition, because: > I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. Tech debt is _inevitable_. Any decision will eventually be debt - rot begins before the code is even finalized. Focusing on avoiding short term gains at long term cost is totally fine, and I think that's the point of your "zero tech debt" strategy, but that's not zero tech debt. And even when maximizing for the long-term, you're picking between options, which means you're picking the FORM of your tech debt, not the existence of it. To return back to my (admittedly anecdotal) experience with "zero tech debt": What happened was a language shift. People would avoid the phrase "tech debt", but still dealt with the reality. The decisions were being made, uncovered debt (such as a paradigm shift in the industry, or a change in dependent technology, or just an anticipated business flow that turned out to play out differently) was hidden. Basically, it seemed fine for a while, but management was getting out of the loop because management had decided an unachievable purity was more important than frank and open communication. The result was what happens any time management pushes themselves out of the loop - at some point, the compound interest on the debt came due. By then, multiple devs had left because in an industry with so much choice, why choose to work somewhere that refuses to face reality? Not selling the long term for the short term is a great approach, but if you're trying to enforce "zero tech debt", I suggest you talk with your devs to see what they think that means and make sure that you're all on the same page, because tech debt is maintenance costs, and those will never be zero. If you're being told they are zero, then there may well be a disconnect.
    - vemv 7y ago
      Great insight. I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind. Definitionally, no methodology makes the unavoidable avoidable? Now, let's say you get to that dreaded point - requirements have changed, dependencies have changed, the industry landscape has changed. Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?
      - neeleshs 7y ago
        Software development is a never-ending procession of tradeoffs. In that context, tech debt and paying it is also a never ending procession. A code reviewer may say a 2 level deep if/else is more readable. But two layers abstraction while complex, may be more adaptable later on. Then again, one may never need it at all. So unless one has a crystal ball, tech debt is mostly visible after the fact. There are some areas that may qualify as "universally accepted", but in my experience that is a much smaller piece.
      - ergothus 7y ago
        > Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one? I feel this is a bit of strawman, though that may not be your intent. As I mentioned in the above comment, wanting to avoid hurting your long term for the short term is fine and admirable. However, I think the distinction between "unavoidable" and "avoidable" debt is somewhat facile and unrealistic. It's a continuum, with points scattered throughout the center. Is this decision the best one? That is debatable, and should be debated, but the result won't be "yes debt" or "no debt". I also said that if someone is shooting for "Zero debt" they should talk with their devs and make sure everyone is using words to mean the same thing. I continue to stand by that, because however clean and rational your personal definition may be, it's worthless if that's not the meaning anyone else is using.
        vemv 7y ago
        Point taken. At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective. So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100% accuracy. But I _can_ follow certain practices and have a given team follow them. Those practices being quite objective, benefitial, and superior to the status quo of the industry.
  - foobarrio 7y ago
    One of the reasons why I sometimes don't like the term "tech debt" is because you can take it on without knowing it. This is not true for financial debt. When you borrow money, even if you're not tracking it, the lender is 100% tracking the debt. If you are in a team that discourages upgrading build systems, code reviews, code quality, testing etc there isn't really anyone that can point to instances where tech debt was accrued or how much there is.
    - smileysteve 7y ago
      > This is not true for financial debt. It is however true with assets; The housing crisis provides a great example; housing is an asset when it is always appreciating; however, if it starts depreciating (2008), it quickly became a liability. This translates nicely to product. Each feature is an asset for selling; until it is found to have liabilities (pii data storage, inability to scale), then the feature either needs work again (requiring reinvestment) or removed (sold).
      - foobarrio 7y ago
        That's a good comparison I haven't thought of before!
scarejunba 7y ago
Iteration speed and quality are directly related, not inversely. Iterative development allows exploring software design considerations fast which means you get to actually good software instead of getting it right the first time. Fast iteration means you can kill ugly design. Slow iteration means you get stuck with a design choice because you discovered its flaws too late.
- vemv 7y ago
  That seems entirely subjective. People may go fast for meeting a deadline, or for iterating as you suggest. Trying to determine what people do is likely a futile discussion. Finally, by writing decoupled, modular software, you are always free to reassemble it later (discarding/rewriting undesired parts), no matter when it was originally assembled.
  - regularfry 7y ago
    This is something that has actually been researched, so it's not accurate to say it's subjective. Higher release rates (i.e. an iterative approach) cause higher organisational performance. See Accelerate, by Forsgren et al.
twiggie 7y ago
You can't have no deadlines at all. The world is moving forward. Military rivals are building their own planes.
- vemv 7y ago
  Would you rather have a bug-free fighter delivered in 2021 or a buggy fighter in 2020? Especially considering that many codebases are expected to have a shelf life of 5-10 years. IME working deadline-lessly doesn't mean you're suddenly knee-deep in a metaprogramming rabbithole. You just do the same stuff, stress-free.
  - Retric 7y ago
    That suggests a 2021 deadline, but many military projects have been 15+ years late. A 15 year old fighter is already in need of updates.
    - twodave 7y ago
      There's a healthy enough difference between an estimate and a deadline, I think. Obviously you want to report progress, but you can do that and work productively more effectively without a deadline, because now you're no longer feeling pressured to lie to yourself and others about what you are capable of.
api 7y ago
Virtually all "management methodologies" are snake oil, Scrum(tm) and Agile(tm) included. They're just ways for high priced consultants to milk deep pocketed companies and governments run by apparatchiks. Occasionally they're also used to milk over-funded startups run by people who want to be up with the latest buzzwords.
bitL 7y ago
Heeey, but how would you get a selfie sub-module into F22 and real-time social media sharing from missile in-flight without Agile? Please don't be so backward, thx.
regularfry 7y ago
No need to imagine, it's been done. Successfully. https://saabaircraftindustry.com/en/roads-to-new-capability/development-skills/agile-methods-in-software-development/ https://saabaircraftindustry.com/en/roads-to-new-capability/...

by vemv 7y ago

smileysteve 7y ago

> when you enjoy zero tech debt and an excellent foundation. This implies that you plan exactly when and where tech debt is accumulating or found. The scrum argument is that by iterating and releasing, you find out where unexpected tech debt is more rapidly; and you go back and fix it. One way that #AgileIsDead happens is when products disregard the tech debt for features even as it becomes apparent.

vemv 7y ago
Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. (I'm open to be convinced) Generally I have witnessed tech debt as something pretty blatant and obvious - generally it's detected in the code review process. Sometimes it's big faults being introduced, more often it's small faults leading to 'death by a thousand cuts'. My current policy is to allow zero tech debt, following the "no broken windows" principle. https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy https://pragprog.com/the-pragmatic-programmer/extracts/softw... That involves a greater investment in code reviews.
- ergothus 7y ago
  > My current policy is to allow zero tech debt I was in an office that had such a policy - it didn't go well. Perhaps it's a matter of definition, because: > I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. Tech debt is _inevitable_. Any decision will eventually be debt - rot begins before the code is even finalized. Focusing on avoiding short term gains at long term cost is totally fine, and I think that's the point of your "zero tech debt" strategy, but that's not zero tech debt. And even when maximizing for the long-term, you're picking between options, which means you're picking the FORM of your tech debt, not the existence of it. To return back to my (admittedly anecdotal) experience with "zero tech debt": What happened was a language shift. People would avoid the phrase "tech debt", but still dealt with the reality. The decisions were being made, uncovered debt (such as a paradigm shift in the industry, or a change in dependent technology, or just an anticipated business flow that turned out to play out differently) was hidden. Basically, it seemed fine for a while, but management was getting out of the loop because management had decided an unachievable purity was more important than frank and open communication. The result was what happens any time management pushes themselves out of the loop - at some point, the compound interest on the debt came due. By then, multiple devs had left because in an industry with so much choice, why choose to work somewhere that refuses to face reality? Not selling the long term for the short term is a great approach, but if you're trying to enforce "zero tech debt", I suggest you talk with your devs to see what they think that means and make sure that you're all on the same page, because tech debt is maintenance costs, and those will never be zero. If you're being told they are zero, then there may well be a disconnect.
  - vemv 7y ago
    Great insight. I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind. Definitionally, no methodology makes the unavoidable avoidable? Now, let's say you get to that dreaded point - requirements have changed, dependencies have changed, the industry landscape has changed. Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?
    - neeleshs 7y ago
      Software development is a never-ending procession of tradeoffs. In that context, tech debt and paying it is also a never ending procession. A code reviewer may say a 2 level deep if/else is more readable. But two layers abstraction while complex, may be more adaptable later on. Then again, one may never need it at all. So unless one has a crystal ball, tech debt is mostly visible after the fact. There are some areas that may qualify as "universally accepted", but in my experience that is a much smaller piece.
    - ergothus 7y ago
      > Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one? I feel this is a bit of strawman, though that may not be your intent. As I mentioned in the above comment, wanting to avoid hurting your long term for the short term is fine and admirable. However, I think the distinction between "unavoidable" and "avoidable" debt is somewhat facile and unrealistic. It's a continuum, with points scattered throughout the center. Is this decision the best one? That is debatable, and should be debated, but the result won't be "yes debt" or "no debt". I also said that if someone is shooting for "Zero debt" they should talk with their devs and make sure everyone is using words to mean the same thing. I continue to stand by that, because however clean and rational your personal definition may be, it's worthless if that's not the meaning anyone else is using.
      - vemv 7y ago
        Point taken. At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective. So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100% accuracy. But I _can_ follow certain practices and have a given team follow them. Those practices being quite objective, benefitial, and superior to the status quo of the industry.
- foobarrio 7y ago
  One of the reasons why I sometimes don't like the term "tech debt" is because you can take it on without knowing it. This is not true for financial debt. When you borrow money, even if you're not tracking it, the lender is 100% tracking the debt. If you are in a team that discourages upgrading build systems, code reviews, code quality, testing etc there isn't really anyone that can point to instances where tech debt was accrued or how much there is.
  - smileysteve 7y ago
    > This is not true for financial debt. It is however true with assets; The housing crisis provides a great example; housing is an asset when it is always appreciating; however, if it starts depreciating (2008), it quickly became a liability. This translates nicely to product. Each feature is an asset for selling; until it is found to have liabilities (pii data storage, inability to scale), then the feature either needs work again (requiring reinvestment) or removed (sold).
    - foobarrio 7y ago
      That's a good comparison I haven't thought of before!

scarejunba 7y ago

Iteration speed and quality are directly related, not inversely. Iterative development allows exploring software design considerations fast which means you get to actually good software instead of getting it right the first time. Fast iteration means you can kill ugly design. Slow iteration means you get stuck with a design choice because you discovered its flaws too late.

vemv 7y ago
That seems entirely subjective. People may go fast for meeting a deadline, or for iterating as you suggest. Trying to determine what people do is likely a futile discussion. Finally, by writing decoupled, modular software, you are always free to reassemble it later (discarding/rewriting undesired parts), no matter when it was originally assembled.
- regularfry 7y ago
  This is something that has actually been researched, so it's not accurate to say it's subjective. Higher release rates (i.e. an iterative approach) cause higher organisational performance. See Accelerate, by Forsgren et al.

twiggie 7y ago

You can't have no deadlines at all. The world is moving forward. Military rivals are building their own planes.

vemv 7y ago
Would you rather have a bug-free fighter delivered in 2021 or a buggy fighter in 2020? Especially considering that many codebases are expected to have a shelf life of 5-10 years. IME working deadline-lessly doesn't mean you're suddenly knee-deep in a metaprogramming rabbithole. You just do the same stuff, stress-free.
- Retric 7y ago
  That suggests a 2021 deadline, but many military projects have been 15+ years late. A 15 year old fighter is already in need of updates.
  - twodave 7y ago
    There's a healthy enough difference between an estimate and a deadline, I think. Obviously you want to report progress, but you can do that and work productively more effectively without a deadline, because now you're no longer feeling pressured to lie to yourself and others about what you are capable of.

api 7y ago

Virtually all "management methodologies" are snake oil, Scrum(tm) and Agile(tm) included. They're just ways for high priced consultants to milk deep pocketed companies and governments run by apparatchiks. Occasionally they're also used to milk over-funded startups run by people who want to be up with the latest buzzwords.

bitL 7y ago

Heeey, but how would you get a selfie sub-module into F22 and real-time social media sharing from missile in-flight without Agile? Please don't be so backward, thx.

regularfry 7y ago

No need to imagine, it's been done. Successfully. https://saabaircraftindustry.com/en/roads-to-new-capability/development-skills/agile-methods-in-software-development/ https://saabaircraftindustry.com/en/roads-to-new-capability/...