Don’t draw diagrams of wrong practices | Hacker News Reader

Don’t draw diagrams of wrong practices

tarmo.fi

30 pointsedw51914 comments

I have been looking closely for years ever since someone wrote on Wikipedia that I was an "advocate" of the waterfall method. There has NEVER been an "advocate" of the method. Nobody has ever said that strict phase-by-phase progression, with no possibility of iteration, is the right thing to do. Never.

Waterfall has ALWAYS been an anti-pattern.

It has NEVER been a practice that ANYBODY advocated.

Yes, people started with design, then they implemented the design, and then they realized there were mistakes in the design, and sometimes, stupid people refused to admit this and change the design, and then they were called out, and told that that "the waterfall method is discredited" or something like this.

University instructors who "taught" the waterfall method were either grossly misinformed (as if this was considered an accepted practice in the real world), or, more likely, trying to make a point about the anti-pattern.

Perhaps you are unacquainted with the long, steady stream of failed enterprise projects. Many of these were build with the waterfall as the primary model. Should the project be successful, any "iterations" are called maintenance, often staffed with deliberatly junior people, with little or no access to the overall intent of the project. Maintenance is thought to be hideously expensive in this context, and rightly so.

So you have worked for (MS) and built organizations that have a far better idea of how to build software than the waterfall method, but believe that there are advocates who believe in the waterfall way of doing things. Fortunately it is becoming less frequent.

Are there companies where maintenance & bug fixes aren't the domain of the junior developers?

I've never seen otherwise unless the junior guys can't handle it and it gets escalated to the people who are trusted with design.

Yes. When maintenance is not considered something you do after you've built the software, but a part of the evolution of said software, you regularly see senior people fixing bugs and such.

[Waterfall] has NEVER been a practice that ANYBODY advocated.

I don't think you're quite right there. It was mandated by the US Department of Defense for years (DOD-STD-2167). Since they were (are?) the biggest software customer in the world, this was influential beyond the DoD.

Although there are a great many blog posts on this subject, they mostly (including this one) are uncredited paraphrases of Craig Larman's excellent research on the history of iterative development. It was Larman who figured out that Royce's original paper described waterfall as what not to do, Larman who figured out the history of how the DoD adopted it anyway (basically, they didn't read the second half of the paper), and Larman who tracked down the guy who had been responsible for that decision. IIRC, they met for lunch in Boston and his first words to Larman were "I'm so sorry!"

The "waterfall" method is comforting because it can be made to reflect a company's existing physical/organizational structure: work passes down the assembly line from Department A to Department Z and then it's done. And of course we'll meet our deadlines, because look, here they are right on the Gantt chart!

So the illusion of control I think is convincing, more so than any Royce diagram.

I have no idea where you got the idea that reflects a company's physical or organizational structure. Not in any company I can think of. The most old-school company I can think of, say, Ford building cars, knows that the very process of building the factory will cause change in the design of the car, and they know that they're going to iterate the design, at least annually, which is something they've done since the 1930s.

Ok, to call it the "physical/organization structure" was probably too literal.

What I'm getting at is what I've seen from waterfall, where responsibility is "handed-off" from department A to department B to department C and then it's "done".

Managers use the waterfall phases to schedule each department's workload, so each team is essentially working in isolation.

e.g.: "Requirements and Design" is one department, "Implementation" is another, "Verification" is yet another. (Design, Developers, QA)

This used to be the standard practice where I worked doing client web development. Random Fortune 500 Company is not going to buy into an iterative development process, because the person at the client company is usually some peon with little real power to adjust budget or requirements as necessary. That is, until it's too late, and their superiors are breathing down their necks because the website doesn't do what they didn't say it should do. Plus, if you don't use an iterative process, you can bill your client for massive change orders.

So there's no real incentive on either side to change the process, unless both companies "get it" from the start that you can't make quality software this way. The likelihood of this decreases dramatically the larger the client.

As far as I remember the waterfall model has been taught to us in Software Engineering class in CS undergraduate degree as one of the most effective. Even at that time I felt a little uneasy with it being so highly structured and inflexible. In contrast I have not seen it being used even once where I work. I feel duped.

In my software engineering class, we were taught that it was an option, but generally not preferred compared to an iterative model. So far so good.

We then proceeded to ignore this entirely and for the rest of the course acted implicitly as if we were using waterfall. Including in subtle ways, such as being given homework assignments due next week with no chance for iteration. An "assignment" in which there is no room for iteration bears absolutely no relationship to the practice of software engineering of any kind.

In hindsight, thinking back to my software engineering course, I'm not sure there's a single thing in it I agree with ten years later, and it's not like any of the things I've learned in those ten years are brand-new knowledge, it was all equally obvious in 1999.

My SE class last semester also said the waterfall model was a fairly good choice, although it "might not work especially well for projects with rapidly changing specifications."

What they didn't say is that describes virtually every project.

I'd say they're right to teach it as such, though. Software Engineering is about nuclear reactor software, traffic flow control software, car injection system firmware, weather prediction grid software, lunar rover software, and, just maybe (but this is at the borderline), ERP software.

Meanwhile, web applications (that aren't Google-search scale projects) don't require any software "engineering"—they're simply designed and then crafted, more like a clay pot than a bridge. They're iterated like a play is rewritten slightly after each performance, based on audience approval and obvious errors, not based on any accepted theorem or body of knowledge that says that the given practice is wrong.

A corollary of that statement is that Software Engineering has no use for most of us here at HN :)

I wasn't aware that the waterfall was really a "method" at all, much less something that was taught. I thought it was an observation or model of the sequential process that tends to spring up once you have specialized groups within an organization. It's not exactly the absence of a development methodology, but the process (if not the term) predates the idea of development methodologies as a topic of concern.

Reply on news.ycombinator.com