3 ms·

> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are. You're ass

> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are. You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices regarding the design. None of these assumptions hold even in conventional engineering projects. The only reason why waterfall processes is used in conventional engineering projects is that it's so expensive to fix problems arising from these sources of failure that it's perfectly fine to deliver working but inadequate solutions.

s73v3r_ 8y ago
"You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements" No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project. "None of these assumptions hold even in conventional engineering projects." Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want. One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.