With due respect that actually misses the problem.
Waterfall works when cost of failure is high (particularly when lives are at stake) and uncertainty in specification is low. There are cases where those criteria are met but those are usually not what we think of when we talk about software. The software that runs the space shuttle, avionics, radiotherapy controls, etc. are all examples where waterfall *is* appropriate in my view. If a stack overflow gives someone radiation poisoning, causes a plane to crash, or a car to accelerate out of control, this is a very different situation than "I want to track what I do for my customers."
Rather the problem is with the type of problem being solved. If you are solving a clear, precise, technical problem the considerations are different than if you are solving a business process problem which will probably be transformed in unpredictable ways by the tool you are writing to solve it.
I think we would both agree that these problems become less when components are more clearly segmented by team and by responsibility and so bounded complexity goes down?
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: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |