Hacker News Reader

Comment by bdefore | Hacker News Reader

Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limited to government or very large corporations. Scrum arrived to slay a mythical beast.

View on HN

It's funny to me that one of the original descriptions of waterfall is actually something we might consider agile: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

It augments the naive waterfall with continual testing and customer feedback among other things that might surprise you.

I agree waterfall did not really exist in most places which is why I called it pseudo waterfall.

But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.

There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs.

What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering.

Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.

Sounds painful. I remember I did have to field questions from management on why one teams velocity wasn't "as good" as another's. They seemed to think it was some kind of globally objective measure rather than something particular to each team and their estimations.

Your example has always been a common conversation. And a bit like The Neverending September, at some point the training became overwhelming. This misunderstanding about velocity has become prevalent, you could maybe say more common than its intention as a tool.

There was a time when software teams didn't meticulously ticket and estimate everything. Hard for some to fathom, but stuff got done if you worked with honorable craftsman. Just differently. #noestimates feels very long ago.

Sounds like you moved on wisely. Aberrations like these vary of course, but along the rise of large tech giants that demand alignment and are threatened by autonomy, it's become more de facto.

It's sad to see small teams take it as a given for how things are done. I genuinely think it deforms and delays the solutions they're trying to make for their customers.

Sadly, this constant push to measure and control all processes and tasks infects everything, not just development.

Enterprise software is appalling at imposing workflows on everything in sight, and they always have pretty graphs and reports for management.

I feel quite strongly that software should serve humans, rather than the other way around. These tools do not exist to help you get your job done, they make you its servant.

Imagine how much more productive we could be if we had tools designed to actually help us. Management could still get nice reports, but some manager might have to knock up a spreadsheet. I can dream...

Please dream out loud. :) What would those tools look like?

I can think of some qualities those tools would have. Ease of use, focused simplicity. Interactions should be voluntary, not enforced by a workflow system. Usage metrics shouldn't be exposed outside its users, giving them flexibility to use it however makes sense for them.

The author points to Microsoft as a typical example of corporate programming in the 1990s.

Yet Microsoft wasn't using a (pseudo)waterfall development model. Quoting Steve McConnell in "Rapid Development (1996) Page 271:

] In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale.

As I've pointed out before, I've read about software development projects at Apple, Be, Commodore, Data General, id, Infocom, Microsoft, VisiCorp and others. None were using (pseudo)waterfall.

I therefore agree with bdefore that it seems to have been "far from ubiquitous and mostly limited to government or very large corporations", and that the era of waterfall was a mythical beast.

I guess it depends where you worked. I certainly don't claim it was ubiquitous, but I personally saw it at a start up and a small software house. Also government, for sure!

I saw it at a local council (serving ~300k people) & a small gas (as in methane delivery) company as well as at a very large telco and in government/defence. It may not have been ubiquitous but it was definitely everywhere I worked.

Yes, "Rapid Development" lists a dozen or more approaches, including iterative prototyping and (modified) waterfall, with pros and cons of each one.

My issue with the standard Agile story repeated here is the lack of any mention of pre-Agile approaches other than waterfall.

Take: "Rather than clearing the way for software developers to build, waterfall gummed up the works with binders of paperwork and endless meetings."

Why is there no mention of any other approach? We can easily point to the Macintosh project, which took 5 years (1979 to 1984). Yet, no waterfall there.

Or, take a closer look at: "Peter Varhol, a technology industry consultant, estimates that in the early 1990s, the average application took three years to develop, from idea to finished product." (That's shorter than the Macintosh project.)

What does that mean? Which industry? What kind of applications? Clearly a lot of "log cabin" PC applications are excluded from that list - just think of all the DB2 and VB applications people wrote in that era. And video games.

In the late 90s/early 00s I worked at two large tech companies that at the time were household names. Granted one no longer exists and neither are what that phrase would evoke today.

In neither case did we do waterfall as people describe it. If anything it was even less process than agile. Sure the gantt charts existed, and sure at a high level things had been drawn out. But in the boots on the ground teams things were a lot more ad hoc. The biggest difference I see from that experience today was that individual developers were handed larger pieces that'd take weeks or more, and had a lot more freedom of action.

Not sure I'd call it better or worse to common scrum setups, but likely a bit of both.

For me too in the 90s it was a lot more ad hoc, with a higher degree of trust in the developers.

I think many people found software quite mysterious. You had to let the wizards perform their strange magic ;)

I think what agile gives us over that world is better feedback cycles.

Yes. This bullshit you describe was real. I remember having managers in 1998 using Microsoft Project and HUGE plotters that were used for nothing but printing out massive Gantt charts. And, of course, having DAILY meeting when we were behind so that our manager could show with great accuracy how behind we were - and complain he needed more people to manage so he could build his fiefdom.

Waterfall also consists of those phases. One core idea of agile is instead of a big design up front to iterate those phases as fast as possible because often the requirements are not clear from the beginning and you have to see if your ideas bring value to the stakeholders. The problem is that not all tasks can be done in a short time and sometimes need more planning. Planning is often neglected in agile environments. In some environments you also know the requirements beforehand (because they stem from the law for instance), agile development does not work there.

I completely agree. In my early agile training, the instructor stated it was good for developing where requirements were unclear or responding to small feature requests quickly, due to the fast iterative approach with feedback.

He also said that agile was not a substitute for planning.

I guess those lessons weren't learned by everyone...

Yep, the design phase shouldn't be an exclusive OR between a large-scale design & small-scale designs with iteration. It should be both: plan the large-scale architecture, marking the bits which are unknown, then iteratively design & build to fill out the unknowns & build the rest of the design. It's a recursive process.

solve([problems]) 1. Define car(problems). 2. Plan a solution. 3. Implement the solution. 4. Test the solution. 5. Document the results. Add any problems discovered to the list. 6. solve(cdr(problems))

Reply on news.ycombinator.com