4 ms·

Paraphrasing a comment on /r/programming about this yesterday: If there is a decent set of requirements, then the framework used is irrelevant.

taneq 10y ago
But Agile, as I understand it at least, is explicitly designed for cases when requirements aren't fully known.
- Zigurd 10y ago
  Moreover, Agile is about realizing there is value in reconsidering your requirements as you discover opportunities, or encounter problems. You may think you know all the requirements. But that it often an illusion or a rigidness that prevents a better result.
- forgottenpass 10y ago
  Agile is designed for that case, but most development methodologies are designed for that case. The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles. Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects. Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.
  - taneq 10y ago
    > but most development methodologies are designed for that case Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product. It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.

taneq 10y ago

But Agile, as I understand it at least, is explicitly designed for cases when requirements aren't fully known.

Zigurd 10y ago
Moreover, Agile is about realizing there is value in reconsidering your requirements as you discover opportunities, or encounter problems. You may think you know all the requirements. But that it often an illusion or a rigidness that prevents a better result.
forgottenpass 10y ago
Agile is designed for that case, but most development methodologies are designed for that case. The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles. Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects. Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.
- taneq 10y ago
  > but most development methodologies are designed for that case Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product. It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.