Comment by benjaminwootton | Hacker News Reader

Comment by benjaminwootton | Hacker News Reader

benjaminwootton

The author is quite defensive about the commercialisation around agile. I don't think this is warranted.

I'm a developer, but I have described myself as an agile consultant in the past.

This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think is a better way to deliver software.

When vendors and consultants start to coallesce around an idea, it usually means that the idea is a good one that is gaining traction, coming down from the ivory tower. It's a positive thing and not something to leave the community that you founded over.

I've heard this argument many times over the years, and it always sticks in the throat a little. I'm evangelising an idea that I passionately believe in but am seen to be selling out the community ideals somehow. I walk the same line on my current venture in the DevOps space.

All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).

I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'.

What was our mantra? "Design a little, code a little, test a little".

Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision.

So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process.

To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on.

I'm old.

>"Design a little, code a little, test a little".

That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1]

>The details vary, to be sure, but the fundamentals remain the same.

I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is. [1] https://en.wikipedia.org/wiki/Waterfall_model

People should stop using the term waterfall to describe any real process. It's only been used to describe a fictitious cartoon of a process, purely for the sake of their argument.

That wikipedia article is a bit of a mess, but read the article at footnote 7:

  http://www.idinews.com/waterfall.html

"There's no such thing as the Waterfall Approach! (and there never was)"

If only that were true! My first employer was a large organization that explicitly embraced the waterfall methodology that we all rightfully deride.

There may have been no capital-W Waterfall approach, but implying that projects weren't routinely being run in a waterfall-esque, staged-handoff fashion smacks of revisionism.

I was there. I was on those projects. They existed, and unless everything went perfectly according to plan, they were messes.

Reply on news.ycombinator.com