4 ms·

I haven't read the doc, but I worked on lawsuits (I'm a lawyer) that at their core were asserting that agile software development isn't as safe or bug proof as

I haven't read the doc, but I worked on lawsuits (I'm a lawyer) that at their core were asserting that agile software development isn't as safe or bug proof as waterfall. Basically in the medical device (or adjacent) space the idea asserted was that 'fail fast' was illegal and didn't have enough safety checks. Agile software development is a tough pill to swallow for non-engineers. The lawyers and business people can't wrap their head around the idea that building iteratively could actually reduce bugs and improve quality - because the way they work is via process planning docs and checklists.

arcbyte 4y ago
The ONLY way to get quality is through quantity. That's the key insight.
- hamandcheese 4y ago
  Quantity of... dollars?
  - no_wizard 4y ago
    I’m betting releases and iteration cycles they’re tied to. The most agile place I ever worked shipped code most days of the week in some fashion. For control reasons we released Tuesday-Thursday not Mondays or Fridays. So was nearly every day something went out. I’m including bug fixes here but nothing got stalled. We had a working iteration loop of Test -> Develop -> Test -> Review -> QA -> Release Lots of automated checks, investment in infrastructure and good architecture made this possible. Ironically one of the smallest companies I ever worked for
  - xboxnolifes 4y ago
    Iterations.
- __MatrixMan__ 4y ago
  "Breaks when you try to use it" is a quality that I can usually achieve on the first try. Or did you mean some quality in particular?
no_wizard 4y ago
I think this is true even in “civilian” industries. Can say doing this for over a decade now that I have worked at exactly one place that followed anything close to what was laid out in the Agile manifesto. Every other place always sings the praises of agile and/or scrum but it’s always just waterfall with ceremonies. I feel like the collective of how software is developed evolved little from circa 2006 The notion that gets talked about at Netflix is “context not control” and I think it would go along way if everyone looked at software development management this way. Too many people try to control software development lifecycles instead of just providing engineers enough context to get their work done and trusting that reasonable people will make reasonable decisions
- beckingz 4y ago
  Large organizations value predictability.
  - no_wizard 4y ago
    IMO it’s not this simple. Culture has more to do with it than anything. See my note about Netflix having this mantra of “context not control”. Managers are less inclined to be domineering in that setting and allow people to do the work in a reasonable way because they are given the context of why their work is being done in the first place. Not perfect but a more than above average way to approach the problem yet this kind of thinking or its permutations have not caught on at all. It’s still top down process oriented models
Jtsummers 4y ago
What a bizarre claim. Agile doesn't mean "cowboy coding" (I've met as many cowboy coders in Waterfall, may it die a fiery death, as Agile projects). Nothing about Agile says, "Don't ever test and validate this system before deploying." Anyone who believes that is, frankly, a moron.
- johndhi 4y ago
  In my experience it was less a lack of intelligence and more results-oriented thinking (they thought we were wrong so they found a way to argue it). If you have twenty versions of a thing and multiple deployments to fix and fine tune it, that means to this person there are 20 plus examples of "mistakes" you made in building it. They were looking for evidence that the software was built with "poor quality controls" and ironically interpreted iteration as evidence of poor build quality.
jasmer 4y ago
Such a great point. I think one way to go about it is to just put the Agile bits inside a Waterfall. Which is frankly how it works anyhow. You can characterize early sprints at 'research'. Later the sprints are just 'sub projects'. I think people could be convinced that 'feature refinement' is a real thing. Put it out in the field, doesn't work the way we want it, and so it needs to be refined. I know that I would hide 'Agile' to anyone outside the team and just talk in simple, easier to understand phases. It's also possible to put checklists in those phases, and if you say someting like '75% features' at such and such phase and assume '25% of that 75% will be reworked' it's not irrational either. But you are right, culture matters.
he0001 4y ago
This is so true. They don’t teach agile in management classes and ‘planning’ generally means years, not t-shirt sizes. I believe that also many economic theories and practices don’t regard agile practices. I’ve always felt that the business and their planning are at odds with the agile ways.
- imglorp 4y ago
  > management classes It would seem they don’t do a very good job teaching how to think about uncertainty, risk, and unknowns, which is what agile is good at addressing. If you want a suit to lose their mind, tell them they can only pick two of feature, quality, or schedule. Waterfall seems a lot better when you have done something before and there's nothing to discover.
  - Jtsummers 4y ago
    > Waterfall seems a lot better when you have done something before and there's nothing to discover. I've said this here on HN before, but the only Waterfall projects I've seen it work reliably were where: 1. The systems were small (in which case any method would work) 2. The systems were trivial (in which case any method would work) 3. The systems were well-understood by the people making them (in which case any method would work) It does not handle large, non-trivial, or novel systems very well. Almost without fail they will deliver late, over budget, or deliver the wrong thing. This can be a win for contractors, though, who get to bid on the rework or sustainment contract for their own work.
zozbot234 4y ago
Building iteratively can reduce bugs and improve quality other things being equal. The problem with how Agile methods sometimes get implemented in practice is that an excess focus on quick-and-dirty iteration to the exclusion of everything else leads to having mountains of very poor quality code, with little to no support structure around it in the form of broader design or documentation. Agile methods advocate for growing these kinds of support structures via refactoring, but this is often not done to anywhere near an adequate extent.
ravenstine 4y ago
Agile is a tough pill to swallow for many engineers, but it's become part of the theology of software development, so everyone's afraid to object to it.

arcbyte 4y ago

The ONLY way to get quality is through quantity. That's the key insight.

hamandcheese 4y ago
Quantity of... dollars?
- no_wizard 4y ago
  I’m betting releases and iteration cycles they’re tied to. The most agile place I ever worked shipped code most days of the week in some fashion. For control reasons we released Tuesday-Thursday not Mondays or Fridays. So was nearly every day something went out. I’m including bug fixes here but nothing got stalled. We had a working iteration loop of Test -> Develop -> Test -> Review -> QA -> Release Lots of automated checks, investment in infrastructure and good architecture made this possible. Ironically one of the smallest companies I ever worked for
- xboxnolifes 4y ago
  Iterations.
__MatrixMan__ 4y ago
"Breaks when you try to use it" is a quality that I can usually achieve on the first try. Or did you mean some quality in particular?

no_wizard 4y ago

I think this is true even in “civilian” industries. Can say doing this for over a decade now that I have worked at exactly one place that followed anything close to what was laid out in the Agile manifesto. Every other place always sings the praises of agile and/or scrum but it’s always just waterfall with ceremonies. I feel like the collective of how software is developed evolved little from circa 2006 The notion that gets talked about at Netflix is “context not control” and I think it would go along way if everyone looked at software development management this way. Too many people try to control software development lifecycles instead of just providing engineers enough context to get their work done and trusting that reasonable people will make reasonable decisions

beckingz 4y ago
Large organizations value predictability.
- no_wizard 4y ago
  IMO it’s not this simple. Culture has more to do with it than anything. See my note about Netflix having this mantra of “context not control”. Managers are less inclined to be domineering in that setting and allow people to do the work in a reasonable way because they are given the context of why their work is being done in the first place. Not perfect but a more than above average way to approach the problem yet this kind of thinking or its permutations have not caught on at all. It’s still top down process oriented models

Jtsummers 4y ago

What a bizarre claim. Agile doesn't mean "cowboy coding" (I've met as many cowboy coders in Waterfall, may it die a fiery death, as Agile projects). Nothing about Agile says, "Don't ever test and validate this system before deploying." Anyone who believes that is, frankly, a moron.

johndhi 4y ago
In my experience it was less a lack of intelligence and more results-oriented thinking (they thought we were wrong so they found a way to argue it). If you have twenty versions of a thing and multiple deployments to fix and fine tune it, that means to this person there are 20 plus examples of "mistakes" you made in building it. They were looking for evidence that the software was built with "poor quality controls" and ironically interpreted iteration as evidence of poor build quality.

jasmer 4y ago

Such a great point. I think one way to go about it is to just put the Agile bits inside a Waterfall. Which is frankly how it works anyhow. You can characterize early sprints at 'research'. Later the sprints are just 'sub projects'. I think people could be convinced that 'feature refinement' is a real thing. Put it out in the field, doesn't work the way we want it, and so it needs to be refined. I know that I would hide 'Agile' to anyone outside the team and just talk in simple, easier to understand phases. It's also possible to put checklists in those phases, and if you say someting like '75% features' at such and such phase and assume '25% of that 75% will be reworked' it's not irrational either. But you are right, culture matters.

he0001 4y ago

This is so true. They don’t teach agile in management classes and ‘planning’ generally means years, not t-shirt sizes. I believe that also many economic theories and practices don’t regard agile practices. I’ve always felt that the business and their planning are at odds with the agile ways.

imglorp 4y ago
> management classes It would seem they don’t do a very good job teaching how to think about uncertainty, risk, and unknowns, which is what agile is good at addressing. If you want a suit to lose their mind, tell them they can only pick two of feature, quality, or schedule. Waterfall seems a lot better when you have done something before and there's nothing to discover.
- Jtsummers 4y ago
  > Waterfall seems a lot better when you have done something before and there's nothing to discover. I've said this here on HN before, but the only Waterfall projects I've seen it work reliably were where: 1. The systems were small (in which case any method would work) 2. The systems were trivial (in which case any method would work) 3. The systems were well-understood by the people making them (in which case any method would work) It does not handle large, non-trivial, or novel systems very well. Almost without fail they will deliver late, over budget, or deliver the wrong thing. This can be a win for contractors, though, who get to bid on the rework or sustainment contract for their own work.

zozbot234 4y ago

Building iteratively can reduce bugs and improve quality other things being equal. The problem with how Agile methods sometimes get implemented in practice is that an excess focus on quick-and-dirty iteration to the exclusion of everything else leads to having mountains of very poor quality code, with little to no support structure around it in the form of broader design or documentation. Agile methods advocate for growing these kinds of support structures via refactoring, but this is often not done to anywhere near an adequate extent.

ravenstine 4y ago

Agile is a tough pill to swallow for many engineers, but it's become part of the theology of software development, so everyone's afraid to object to it.