[jaywalk]

My oven is Internet connected. It can't be turned on remotely unless I press a button on the oven itself, and even then it'll only allow it once.

The WiFi functionality is also such total garbage that it'll only stay connected for a few days, and requires physically unplugging and re-plugging the power to the oven to get it to reconnect.

[paranoidrobot]

> It can't be turned on remotely unless I press a button on the oven itself, and even then it'll only allow it once.

I'm not sure I'd be willing to believe a manufacturer on this. This feature is probably implemented in software, rather than hardware - simply because it's cheaper.

The idea of any of these home appliances being internet connected really blows my mind.

[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.

[RobertMiller]

> It can't be turned on remotely unless I press a button on the oven itself, and even then it'll only allow it once.

That it's possible at all suggests that the oven is only one bad firmware update away from turning itself on when you don't intend it.

Conceivably such a limitation could be built into the hardware; e.g. with a button that works like a circuit breaker. Set to break after the oven starts once and requiring the user to manually reset it. But the odds of it actually being implemented in this way, rather than pure software, is virtually nil.

[jaywalk]

I agree with you. But it's just the oven, so the risk is just wasting some gas and heating my house up a little until I notice. The cooktop burners can't be operated remotely, so there's no risk of unintended open flames.

Also, because of the crappy WiFi it's almost never connected anyway.

[djbusby]

Jajaja! My WiFi oven can't burn my house down cause it's WiFi code is worse than it's heating-element code.

[InitialLastName]

Your modern oven probably has an electronically controlled ignition instead of a pilot light. What would stop the oven from opening the gas valves without igniting, potentially creating a high-risk situation if there are any issues with the seal?