4 ms·

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 c

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.

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.