5 ms·

> I don't think we should be desiging jet fighters in 2 week sprints. Airframes probably can't be modified like that. So it follows that, within a waterfall pro

> I don't think we should be desiging jet fighters in 2 week sprints. Airframes probably can't be modified like that. So it follows that, within a waterfall project, the flight software shouldn't be developed agile either. Do you have any basis for that position? I think using agile principles (ie making small modifications and testing them frequently to get feedback) seems like a great way to design a complicated piece of machinery.

JoeAltmaier 8y ago
Its a great way to churn through hundreds of small tasks, like hooking up database queries to web pages or changing graphics on a site. Its a terrible, terrible way to try to design complex control systems. They must be studied and modelled and analyzed by experts in processes that have absolutely nothing to do with '2 week sprints'. =
- lgunsch 8y ago
  What is terrible about iteratively refining a complex design as you gain feedback from its implementation?
  - AnimalMuppet 8y ago
    Stronger: What's worse about "iteratively refining a complex design as you gain feedback from its implementation", compared to "not iteratively refining a complex design as you gain feedback from its implementation"?
  - JoeAltmaier 8y ago
    And what does {what you said} have to do with 2-week sprints?
- SamuelAdams 8y ago
  By the time developers are working on the change, the design should already be complete. An assembly line worker isn't going to be considering the design of a car: they are going to add this one part according to the blueprint, and move on. They trust the engineers / architects' plan, which should have already been done by the time they started building.
  - jrochkind1 8y ago
    Have you seen software work well when developed like that? If so, what kind of software, in what kind of an organization and other context?
  - williamdclt 8y ago
    Definitely not a good way to go about software development, and one of the things agile avise against. To have a "complete" design (what does that even mean), you need perfect requirements (what does that even mean), and perfect requirement collecting has been many many times proven to be virtually impossible. You'll get an imperfect design that you'll have to work around. In addition, you'll have waited god knows how much time for those design, while you could have been developing stuff and validate that it actually solves problems for your users. Agile is not about making devs into assembly line workers, nobody's pretending that works (though some people are still trying to do it without realising it)
    - jrochkind1 8y ago
      oh, some people are definitely doing it and realizing it! Some managers definitely think agile processes are about making developers into interchangeable widgets and maximizing their efficiency. I agree that this is close to the opposite of the original intent.
    - AgentOrange1234 8y ago
      To play devil’s advocate, I’ve certainly seen plenty of cases where people start coding something—anything—with no coherent plan that they can articulate regarding how it is even supposed to work. I grok the value of learning more as you explore the solution, but there’s a huge value in planning as well as you can ahead of time. The cheapest code to change is the code you never mistakenly wrote in the first place.
      - closeparen 8y ago
        Documents are not automatically cheaper than code.
- wenc 8y ago
  I know something about complex control systems (MPC implementations). There's a lot of trial and error involved. Breaking the task down into small composable tasks is definitely helpful. There are definitely many tight feedback loops that are necessary, whether they are 2 weeks or longer. Things get tweaked all the time, especially in production. There's stuff that don't show up in testing, and there's cases that cannot be anticipated. There's definitely some control analysis to identify default tuning parameters, but the proof of the pudding is in the eating. The design tuning parameters are only initial values -- they are tweaked online while the plant runs. There's an upfront spec but that spec only provides guidance. The real world will often surprise you. There are elements of waterfall at play, but the entire process by necessity cannot be waterfall.
  - JoeAltmaier 8y ago
    And what about that says '2 week sprints'? It takes as long as it takes to do each step.
    - wenc 8y ago
      Are you talking about "agile" or about "2 week sprints" specifically? That might help clarify your position.
    - jacques_chester 8y ago
      What about agile says '2 week sprints'? It takes as long as it takes to do each step.

JoeAltmaier 8y ago

Its a great way to churn through hundreds of small tasks, like hooking up database queries to web pages or changing graphics on a site. Its a terrible, terrible way to try to design complex control systems. They must be studied and modelled and analyzed by experts in processes that have absolutely nothing to do with '2 week sprints'. =

lgunsch 8y ago
What is terrible about iteratively refining a complex design as you gain feedback from its implementation?
- AnimalMuppet 8y ago
  Stronger: What's worse about "iteratively refining a complex design as you gain feedback from its implementation", compared to "not iteratively refining a complex design as you gain feedback from its implementation"?
- JoeAltmaier 8y ago
  And what does {what you said} have to do with 2-week sprints?
SamuelAdams 8y ago
By the time developers are working on the change, the design should already be complete. An assembly line worker isn't going to be considering the design of a car: they are going to add this one part according to the blueprint, and move on. They trust the engineers / architects' plan, which should have already been done by the time they started building.
- jrochkind1 8y ago
  Have you seen software work well when developed like that? If so, what kind of software, in what kind of an organization and other context?
- williamdclt 8y ago
  Definitely not a good way to go about software development, and one of the things agile avise against. To have a "complete" design (what does that even mean), you need perfect requirements (what does that even mean), and perfect requirement collecting has been many many times proven to be virtually impossible. You'll get an imperfect design that you'll have to work around. In addition, you'll have waited god knows how much time for those design, while you could have been developing stuff and validate that it actually solves problems for your users. Agile is not about making devs into assembly line workers, nobody's pretending that works (though some people are still trying to do it without realising it)
  - jrochkind1 8y ago
    oh, some people are definitely doing it and realizing it! Some managers definitely think agile processes are about making developers into interchangeable widgets and maximizing their efficiency. I agree that this is close to the opposite of the original intent.
  - AgentOrange1234 8y ago
    To play devil’s advocate, I’ve certainly seen plenty of cases where people start coding something—anything—with no coherent plan that they can articulate regarding how it is even supposed to work. I grok the value of learning more as you explore the solution, but there’s a huge value in planning as well as you can ahead of time. The cheapest code to change is the code you never mistakenly wrote in the first place.
    - closeparen 8y ago
      Documents are not automatically cheaper than code.
wenc 8y ago
I know something about complex control systems (MPC implementations). There's a lot of trial and error involved. Breaking the task down into small composable tasks is definitely helpful. There are definitely many tight feedback loops that are necessary, whether they are 2 weeks or longer. Things get tweaked all the time, especially in production. There's stuff that don't show up in testing, and there's cases that cannot be anticipated. There's definitely some control analysis to identify default tuning parameters, but the proof of the pudding is in the eating. The design tuning parameters are only initial values -- they are tweaked online while the plant runs. There's an upfront spec but that spec only provides guidance. The real world will often surprise you. There are elements of waterfall at play, but the entire process by necessity cannot be waterfall.
- JoeAltmaier 8y ago
  And what about that says '2 week sprints'? It takes as long as it takes to do each step.
  - wenc 8y ago
    Are you talking about "agile" or about "2 week sprints" specifically? That might help clarify your position.
  - jacques_chester 8y ago
    What about agile says '2 week sprints'? It takes as long as it takes to do each step.