Most of us would probably agree that their method is worse than more modern methods, but spending time making fun of them is like making fun of someone for driving an old car. You could be working on your startup right now.
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.
Pure[1] waterfall is doomed from theoretical point of view. You cannot control a system without a feedback loop, unless you have a 100% accurate knowledge of system's state and future evolution. Waterfall lacks feedback loop => you can't really expect much from it.
[1] - in real life there's always some kind of feedback loop in the process; I'd argue that the primary reason why Agile methodologies seem to work better is that they have a much, much tighter feedback loop than waterfall.
Whether or not one drinks the koolaid doesn't matter much.
15 years ago, 1-3 year release cycles were the norm. Now they're uncommon, and becoming less and less so. Some well-regarded shops (e.g., Etsy) now release many times per day. This isn't driven by what process is fashionable; it's happening because of improvements in technology and the way the Internet has shifted everybody's expectations.
Whether you're officially using some Agile(tm) method or not, you'll have a lot in common with those folks if you meet user demand for faster delivery. There are some niches that are lagging on this trend, but my pals in those areas still feel the pressure. They'll still be able to be waterfall-ish for a while longer, but I doubt it will be forever.
I can. I'm seeing automated tests. A whole lot of automated tests. Unit tests, performance tests, integration tests, executable specifications, tests with real hardware.
I can be done; you have to optimize for what's important to the project at hand.
People have been doing it with medical devices, so I don't think it's impossible. I agree it would have to be done differently, but then avionics waterfall has to be done differently than order-entry systems waterfall, so that's nothing new.
