[ncr100]

How did software engineering get to the point where this kind of low quality update is shipped "too often" for serious circumstances like a physical oven? Like it's hardly notable news anymore for something like this to happen. It's frequent.

I worry that agile is largely responsible, and has mutated into a pipeline for garbage, though I don't have any evidence to confirm that suspicion.

[throw10920]

I don't think that the problem is unique to software engineering - manufacturers have been skimping on engineering quality for centuries. I believe that the problem is worse with software because (a) it's harder to judge quality for software than for physical goods and (b) most consumers seem to have been brainwashed into having much lower standards for software than for hardware.

[switchbak]

Agile was in use for many years before this craziness started, I think you need another explanation.

[wpietri]

I don't think "Agile" is responsible, but it is a supporting character here for sure. Let me give a little history from my perspective.

I got involved in that movement before the word "Agile" existed; I was really interested in the ideas coming from the Extreme Programming folks and had tried them out on a small project in 2000. All of the people I met early on really wanted to do software well; the question was how to do it well and responsively. Unit and acceptance tests were just part of the process [1], and Kent Beck also wrote Test Driven Development By Example [2] around then. So in my view there was strong early interest in quality.

But this was all happening during the rise of the internet, which changed people's expectations for software delivery. Previously, releasing every 18 months was seen as reasonable. Suddenly the web was changing people's expectations. (Although not as fast as you'd think; a consultant pal told me in 2004 that Weight Watchers still had an annual release cycle for their website.) Executives and managers were under pressure to deliver faster.

As I wrote about elsewhere [3], that created a need for Agile that was filled not by the humanistic culture and quality-oriented practices of my end of the Agile world, but by consultants and certification programs watering down the material until executives could slap some new labels on their same old bullshit and call it Agile.

It turns out that bullshit long predates Agile. If you go back to Royce's original 1970 paper on Waterfall [4], one of his big points is that it doesn't work. Why, then, did it become the predominant way to organize software projects? Because it feels good to managers. For most of the project, it gives them a feeling of control and competence. That feeling is false, as it just delays all of the real-world feedback until near the nominal end. But they can perform confidence and competence to their boss, which is vital in managerialist [5] organizations.

So I totally agree with you that Agile on average has mutated into a garbage pipeline. And that happened through a whole industry that produced manager-friendly process theater that threw out a quality focus and most of the Agile values, while using the Agile labels. But I think the real responsibility lies in our management culture and values, which both precedes Agile and whose harm extends well beyond it.

[1] http://www.extremeprogramming.org/map/loops.html

[2] https://www.oreilly.com/library/view/test-driven-development...

[3] https://web.archive.org/web/20170923232057/http://agilefocus...

[4] https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...

[5] See, e.g., https://www.bloomsbury.com/us/confronting-managerialism-9781...

[anamax]

> Why, then, did it become the predominant way to organize software projects? Because it feels good to managers. For most of the project, it gives them a feeling of control and competence. That feeling is false, as it just delays all of the real-world feedback until near the nominal end. But they can perform confidence and competence to their boss, which is vital in managerialist [5] organizations.

Waterfall is not just "feels good" - it decouples their evaluation from their performance.

Until the end, everything is good because there's no measurement to show otherwise. At the end, measurements that show things have gone wrong merely prove that some past manager failed.

The only way to fail is to be a manager throughout the whole project, and management rotations guarantee that that never happens.

It's not just software. The scheduled manager tenure at at least one of the largest semiconductor companies is one year shorter than the design->ship cycle.

[wpietri]

Oh, for sure. I think that's an important component in why it feels good to managers. It's like the "baby driver" toy, the fake steering wheel and console you can give to toddlers. They get to turn the wheel and press the buttons and feel very important.

And I'd add that at the end of the waterfall cycle, metrics often (and incorrectly) show that the workers failed. After all, they said they were 95% done just a bit ago, and now they're suddenly not done. It's very easy to shift blame to them.

As contrast, a lot of the effective Agile techniques don't actually fix problems; they just shorten the feedback loops so problems surface sooner. That's part of why fake Agile won out; managers didn't adopt any of the bits that would make them feel uncomfortable or expose the very real problems with how they run things.