You have a choice of koolaid. The waterfall brand is implicit in the statement "We don't write a line of code until we know your business as well as the people who keep it running every day." - it is founded on the assumption that you can finish requirements for the entire system before starting to deliver working software, and no feedback or iteration is needed.
My experience is that for the majority of software projects, this assumption is horribly broken. And even in fairly well known problem domains where it might work, for the majority of business users wanting new software, the ability to communicate every detail of what it is that they want is horribly lacking.
Scope creep, architecture problems, unanticipated requirements etc. can and does break waterfall projects; this was well known 10 years ago. The probably of it going wrong rises with the size of the project, and it's a curve that's well above linear.
There are two ways out: You can plan for change or you can make the penalties against change more severe - roughly, do even even more big upfront design and penalise change requests; or do less of upfront design, iterate and embrace change. In many cases the "big upfront design" way is impractical in time and expense.
The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.
Very true, and I should have picked an earlier date. But I was erring on the side of caution, and it somewhere between 1990 and 2000 when agile methods, which explicitly reject big upfront design, became mainstream.
I also have the choice to ignore all the methodology snake oil salesmen and actually write software. Every "methodology" is bullshit. The new ones are not any less bullshit than the old ones. The fact that your response assumes I must love the old version of "follow our stupid manager nonsense" is really pretty sad. You honestly can't even imagine a world where I might think all of the bullshit is equally worthless? I have to be an adherent to one of these religions?
That response is even sadder. I haven't chosen the "just code" koolaid, but your religious beliefs are so deeply ingrained that you can only perceive me through that lens. As a result, you miss out on the great big world of "every situation is different and you should do what is appropriate instead of what some dipshit hawking books and seminars says".
Actually, both of my previous comments made mention in passing of situations where I though a method wouldn't work. You say "every situation is different and you should do what is appropriate" but make no mention at all of which method is appropriate for which situation.
Books and seminars, we got these, but good agile is done by adding in some open source software tools, a whiteboard, pens and cards, and people with enthusiasm and an open mind. The last one is most important.
If we're still talking about the original post, then absolutely it's a belief system. Not a very well thought through one, though.
My experience is that for the majority of software projects, this assumption is horribly broken. And even in fairly well known problem domains where it might work, for the majority of business users wanting new software, the ability to communicate every detail of what it is that they want is horribly lacking.
Scope creep, architecture problems, unanticipated requirements etc. can and does break waterfall projects; this was well known 10 years ago. The probably of it going wrong rises with the size of the project, and it's a curve that's well above linear.
There are two ways out: You can plan for change or you can make the penalties against change more severe - roughly, do even even more big upfront design and penalise change requests; or do less of upfront design, iterate and embrace change. In many cases the "big upfront design" way is impractical in time and expense.
Edit: I found the old article on this subject: "Theory P and Theory D of software construction: Which theory fits the evidence?" http://weblog.raganwald.com/2007/06/which-theory-first-evide...