I think there are two problems with the waterfall approach. The first is that it separates either by team or by time design from development. One thing that is hard to learn except from experience is where and when things should be designed first or left for later. This doesn't mean always one or the other....
The second is that requirements always change, but they don't always change in the same way. Again, this is domain-specific. So the waterfall method as I point out, is applicable in some cases.
What I see you say though is that one does need to design before coding. This I agree with. That a waterfall in miniature is helpful. This I agree with too. So I am not actually sure where we disagree.
The point of subsidiarity is to ensure that design and coding are closely tied both by team and by time, and that the pieces are small enough that the design can be done right. That has a lot in common with both waterfall and agile methodologies.
In reply to Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |