Hacker News Reader

Comment by jongjong | Hacker News Reader

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance.

Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in the universe, the next decade, the role barely even exists... What we need more of is common sense.

View on HN

> The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance.

I'm feeling grumpy and decaffinated this morning, so I'll just note that you can't sell books and courses and conferences on "balance and nuance".

But saying things like "everything is somewhere in the middle" and "use common sense" is just as much marketing speak. It's meaningless to the point it's very successfully used in both marketing and politics (but I repeat myself).

The key thing is you can set the parameters so that whatever you're selling happens to fall squarely in the middle. And of course anything can be common sense so long as you can successfully ridicule the alternatives and describe your solution in a way that sounds plausible(ish).

The reality is that it's not exactly "in the middle" either. It's the simple fact that we must really think and carefully consider these decisions and processes. But the vast majority of people don't want to think. They want recipes to follow.

That's why anything that provides a recipe, like scrum, OKRs and so forth, will get sold as a solution for all of our problems. And inevitably lazy people will follow it.

It ALWAYS depends on the context in which these processes are in, but most don't want to spend real time figuring this out. Just adopt what Google, Spotify (squads anyone?), <insert hyped company here> uses.

Oh I am sure you could come up with myriad processes, rituals and ethos and give it a snazzy name like “zero-sigma” (alluding to being the average way)

You should be grumpy and decaffeinated more often, them's the cracks through which the truth shines.

Everyone is vulnerable to it, but software developers are particularly prone to thinking that one true algorithmic "recipe" can be designed that leads to success if only it could be faithfully executed in the organisational CPU.

Discovery vs design is the real dichotomy. When discovery is needed, move in small steps with lots of discussion. When design is possible, move in big steps with detailed specs

We’re biased to overestimate our understanding of problems, so we should lean towards discovery mode and small steps

Dysfunctional agile has detailed specs and little discussion (no discovery, myopic design)

100%. I'll add that dysfunctional agile can also insist it is discovery, when in fact they just won't hire people capable of design.

> nobody advocates for balance and nuance.

Some people do, but they don't get the views or the support.

People are gregarious, they want to be part of a team, middle ground is not a team, unless you create a new name for it. People tend to give support to whoever hates what they hate, not to those who love what they love. So the middle team shouldn't be sold as "the good parts of A and B" but as "we hate A and B".

For example, in tabs vs spaces there's the "tab for indentation, spaces for alignment" bunch, that (we) usually try to sell it like "we use tabs, so you can set the viewing space as you need, and we use spaces so it's neatly aligned" and people don't listen to us.

What if we called it "tabspacing" and defended it like "spaces for indentation are wrong because there are people with visual impairments that need extra space to see things right, and just tabs are wrong, code looks ugly, also if you use space and tabs interchangeably it's wrong, the people with problems will see the code differently than the people without, there will be errors."? Then people might listen to us if they hate one of these things.

So yeah, that's why there are so many ways to do projects: waterfall, agile, scrum, kanban, scrumban, XP, ... .

> So yeah, that's why there are so many ways to do projects: waterfall, agile, scrum, kanban, scrumban, XP, ... .

Bit of a weird mixing of levels there: Everything you mention after "agile" is (more or less) "agile".

Excellent comment.

I'd just add that scrum and waterfall are both more useful in explaining to management and junior engineers approximately how the team/project works, than in actually running the team/project.

Honestly I've never seen a waterfall model implemented without iterations. And you can always update the top-spec at later date if needed its just more difficult.. Which it should be.

This. When agile folk talk about waterfall, they're describing something that I've never seen in practice, even from far before "agile" was a thing.

> Honestly I've never seen a waterfall model implemented without iterations.

I have. It didn't reach the end.

People should read Royce's paper that popularised Waterfall. It has iterations, sadly it appears most people stopped reading after Figure 2.

https://www.praxisframework.org/files/royce1970.pdf

Thanks. 1970. It also talks about building a prototype, eg one to throw away.

Yup, 1970. The Mythical Man-Month was published in 1975.

Our industry is well on the path to ignore the obvious truths for 50 years...

Yeah - I mean, when I wrote the comment I ignored all the absolute disaster-projects I've seen. But those where doomed on so many levels I don't even wanna blame waterfall or agile or the in-betweens.

So, "if you ignore the ones without iterations, I've never seen a waterfall model implemented without iterations."

We can't be sure there wouldn't have been any iterations. In (what's traditionally been called) the waterfall model, there's so long between iterations that the project has time to fail and be scrapped before there ever is one.

Hah yeah i guess you can interpret it like that, but i give the same leeway to agile when they skip the retros and the planning before the sprints etc. You cant blame the process if you dont even make an attempt of adhering to it :)

I have seen exactly that - no iterations. Mostly it was customer waiting for the finished product and that was the first time they've seen it.

As an improvement, sometimes the project management *forced* the customer to make some checkpoints along the way, but they were a far cry from real iterations.

Huh? I’ve never seen scrum fully implemented. It’s always been pick and choose.

Does YMMV?

Am reminded of similar defences used for Marxist communism. "Oh, it only devolved into totalitarian misery every single time they tried it because they forgot to xyz".

everywhere I’ve seen it implemented scrumm is not at all the opposite direction - it’s just waterfall with a two week scheduled whipping meeting.

> scrum is too much

Surely scrum is too little? Most lowercase-a agile people consider it more of a stepping stone into agile.

Depends what you mean. Too much flexibility, true agility? No. Too much process, ceremony, empty ritual? Oh yeah.

And no, AIUI most original-ideals-agilists consider (much or most of) Scrum a stepping stone away from "agile".

Just out of curiosity, are there any non-startup non-tiny companies whose core business is self built software (or a service that runs on said software) that _actually_ and _in practice_ follow the agile manifesto?

I'd say yes - I knew of several in the Germany (Berlin/Hamburg) area a few years ago. In my experience, actually doing agile works better in places with less middle management (just a theory).

Reply on news.ycombinator.com