Hacker News Reader

Comment by doctor_eval | Hacker News Reader

> "Agile: Nope, this one’s in the bin, I’m afraid. It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”. We have to find a new way to discuss the idea that maybe we focus on the working software and not on the organisational bureaucracy…"

Yup. :-(

View on HN

May be we should try 1990's style waterfall dev shop. Play Radiohead and Pearl Jam in the office. Everyone wears shorts + tennis shoes with super long white socks. Monthly powerpoint updates on how things are going, PM gets to have some fun with sharpie markers to tick off checkboxes next to each feature that was planned. Dedicated QA department, and they have the coolest arcade machine, it is the Street Fighter machine from 1 Arcade! Ritchie, one of the frontend devs, was able to hack it so it also accepts Doge coin. Morale is high. Project is over by October, 2 months early, and everyone hires a VW bus to go on a road trip. Customers are delighted and next year starts with another waterfall project.

You made this sound so appealing, I actually want to work on a project like that now.

Frontend devs? It's 1990s!

Arguably - if you knew about RS232 and friends, were familiar with some terminal hardware (I knew more than I should have about Wyse 60s), understood the tty interface, and programmed using terminfo/termcap/curses… then you might be called a front end programmer from the 90s.

Which, dear god, I just realised I was a front end programmer in the 90s!

AFAIK, waterfall was always a straw man meant to knock down. Nobody sane ever did a pure waterfall model. The model came from http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... and describes it as risky in that very paper. Notice diagram 2 (the waterfall), 3 (the dream) and 4(the reality).

We had expensive agile consultants coming in a bit after 2000. They were telling us the current official process, RUP, was waterfall, and we were completely misguided. Of course, this was a typical management-saves-face move: Devs were asking for using RUP as described (i.e. more iterative), even if managers expressly forbade the use of agile processes up to that point. RUP as intended was basically doing 2 to 4 week iterations, each a mini-waterfall (thou shall not call them sprints).

Somehow, expensive consultants delivered an agile more waterfall than RUP.

The actual value from RUP was a clear description of who does what, who requires what, and how do we call each part of the process. The Agile consultants saw no value in this, and gave us service based service service services implemented by services. We had standups reused as meetings to find out if service was meant as ITIL/SOAP/process/micro/business/something nobody ever heard of. This distinction was important so we could fill in all the important agile documents, which were not meant to be read by anyone, but filling them in was the only way us lowly peasants would not stray from the true golden agile path.

Oh well, if there is an ASCII code for the END-OF-RANT character, you can place it here: <<EOR>>

Ha, this is a good rant and I like it.

Rational was all that and more in the 90s but ultimately AFAICT they were trying to make design into a coding exercise under a different name and with a fancy “language”; but that’s what code is for.

Unfortunately my reality has been that some shops and some managers actually do believe that the process is design -> build -> deploy and that any errors or delays in step 2 are the engineering teams fault.

I mean, they don’t say that bit out loud or anything.

I remember working at a company whose "agile transformation" was a disaster, costing the company boat loads of money. After that, we used RUP because agile was a dirty word in that office. We even had posters and such on the walls praising RUP.

Nothing actually changed. Standups became morning meetings, sprints were iterations, sprint review became feature review, and sprint planning became elaboration meetings.

Well, it's very difficult (and probably mis-guided) to throw away waterfall completely. In reality, most "not waterfall" approaches are just "smaller waterfalls" with less formailty. You still need some semblance of requirements (what you want to build), some amount of design, you need to implement, you need to test, and you need to maintain.

Those steps could take months, weeks, days, hours, or minutes. And they could require a lot of written documentation with format reviews, a few discussions between people, or some thinking.

In my world, the detailed design happens as late as possible, and is quite fluid, as we get feedback from the implementation. This is certainly my main take away from DDD.

In waterfall as I understand it, each step is separated in time and team, and the feedback loop from implementation is lost.

Sadly agree here. Maybe we can find a shibboleth. Or is there one and I don't know it!? Oh no!

The term "waterfall", like the terms "capitalism" and "meritocracy", was coined to criticize the (previously unnamed) concept that it defined. "Waterfall" was Royce's term for the way software projects ended up being organically managed by people who weren't putting much thought into optimizing their organization. While I definitely agree that the "waterfall" style of "define everything up front, and then do all the stuff that you defined" is absolutely braindead, the alternatives are unfortunately even more braindead.

So true. I'm borrowing this!

Reply on news.ycombinator.com