BUY A SNORKEL!

Those are raindrops falling on your head!!

I read incessantly - nothing "all the time", but lots of stuff "sometimes".

I've just read a blog entry by Jason Gorman called "Challenging the Waterfall Delusion" on testingreflections.com. A warning here - testingreflections.com is populated predominately by the Contextual Posse (CP), so if you find yourself irritated by the CP, save yourself an apoplexy.

I knew what would follow by the title alone - my immediate thought was "young, inexperienced, and uninformed". Although that sounds insulting, it isn't. All of those things are curable. Only stupidity is to the bone.

So I'm going to do my poor best to cure what is the real delusion here, which is an opinion based on misinformation. I think I'm qualified to discuss this topic - when I started in this business there was no internet, no C/S, and no PCs. Waterfall methodology was the accepted "way to do things". I worked on many successful waterfall projects. That, to me, is the key to understanding and being expert on any methodology. Have you worked on a successful project using that methodology? If not, you will be biased against that methodology even if it makes the most sense for the environment and company in which you work. You don't really understand the positive and negative aspects of working through a project using a given methodology until you've actually walked the walk. Since that time, I've continued to be gainfully employed in QA/QC, watched the changes in the field, and worked on hundreds of projects pretty much using every type of methodology you could name.

So let's talk about waterfall. The Real Deal, not the assumptions made by people who don't remember dumb terminals and have never worked on a project that "admitted" to using waterfall technique.

I've never, in more than 25 years, EVER worked on a waterfall project of any size whatsoever that wasn't broken down into workable pieces or that was moved into production in one big "bang". In addition, do you realize the quality of software products over the past 20 years has gone down, not up? Do you think that indicates your predecessors were stupid or that we do things "better" now?

No. Back in the "olden days", breaking a large project into smaller, workable pieces was called "phased delivery".

And there you have it, folks. That's the only freakin' difference. "Phased" vs "incremental".

Terminology.

You're indulging in a myth if you think users were not involved early and often in the process. You're indulging in a myth if you think there was some kind of gigantic, all-encompassing design document at the get-go.

And that, my dear Watson, is why those "poor deluded people" believe the way they do. Poor "crazy folks".

While we're at it, let's talk about plan-driven development, since it was part of the bad juju associated with (shudder) waterfall methodology.

Has anyone out there got a PMP certification? Gone through PMP training? Been a PM? Do you know what PMs are taught?

Everything, and I do mean everything, is driven by a plan, regardless of project methodology.

Do you have a due date for ANY of your work? Do you know what needs to happen in order to make that date? Then you're driven by a plan, which is driven by due dates, costs, and several other factors, like time and resource availability.

I have yet to see a CEO or CIO walk into a development director's office, tell them need Project X for user Y, and then pat them on the head and say "let us know when it's done".

They want the project scoped out, costed, and planned - REGARDLESS of project methodology. They want progress reports and information on spend to date. Every project usually consists of a team effort where everyone strives toward some sort of organized common goals. That indicates there has to be some sort of plan.

So overall I don't think we as a field are unable to establish standards of quality or professionalism because "there's not one thing that we all agree on". I think we're unable to agree on terminology for what we do.

The Contextual Posse (CP) have heuristics and oracles. Others have boundary tests, cause-effect graphing, etc. But if I put 2 talented, trained testers from both camps into a room and have them test the same field, they come up with exactly the same tests. We all have plenty in common.

However, the PMP folks have it all over us in this regard. They have ONE recognized standard certification and all of them speak the same "language" using the same terminology. There are good PMs and bad PMs with certifications, but the same is true of ANY certification. It is an indication of understanding and acceptance of a basic set of principles proven successful in the field. They are not an indication of talent or ability to apply those principles.

So the next time your organization works some small project that doesn't even need to be broken down into small parts, produces some sort of spec, designs and develops a products, tests it, and installs it (all with user involvement), then break out your umbrella. Those raindrops falling on your head might not be a waterfall, but they're at least a small cascade.

And if you work on a large effort broken down into workable slices, maybe some swim fins would be in order....

I'm sure all those poor demented bastards that can't recognize the obvious superiority of iterative and incremental methodologies (mainly because they have a lot of years of experience and feel it's all the same) would be happy to buy you lunch. How do you feel about "Crow en Croute"?

Just as an general comment, the reason people don't just give up the original names for the same processes is because frankly, it gets really tiresome over a period of time to have some new group come along and rename a "tire" to a "rubber vehicle doughnut". I'm not quite as stubborn as some of my counterparts - it doesn't matter much to me what a process or technique is called, as long as we all understand each other. But don't expect people with more experience than you have to jump on your bandwagon just because you prefer to check the pressure in your rubber vehicle doughnuts. Some of them are very busy and don't have the time or inclination to add another funky Moniker du Jour to their vocabulary. And (go figure) I think people in our field are exceptionally stubborn and opinionated, and that those traits have nothing to do with age, sex, location, or any other type of demographics. Maybe it's just the nature of our work.

Again, I think we, as a profession, should be looking for what we have in common and not for our differences, which are primarily terminology-based or predicated on when the activity takes place in a given project cycle. I see no reason we couldn't get together and agree the heuristic "overwhelm the input field with characters" is a boundary test. Wouldn't it be totally cool to COMBINE those types of concepts into one internationally agreed upon set of principles? "A boundary test is something which tests X. Common heuristics for testing boundaries are as follows....".

We do the same work. We care about the same things.

Call me a dreamer.

(sigh).