[hueving]

Right, if it mentioned those, search would still be the version we saw in 2007. None of the other products would exist yet because they would still be conducting user studies based on wire frame mock ups of workflows designed by committees of behavioral psychologists.

That's a bit dramatic, but when your product development has a fast turnaround for fixes (git push vs 100 million dollar recall) and it won't kill people when it breaks, you should immediately throw most of that process shit out the window.

You can't be competitive in consumer SaaS if you get bogged down in 'real engineering' processes.

[nickpsecurity]

A clear statement of what you're going to do, some constraints on the design a la Design-by-Contract, and languages/libraries that mitigate errors by design are so easy to do that small shops do them on a regular basis. Ada/SPARK, Eiffel, Ocaml, and Haskell are examples with steady business in industry with last three used on relatively-fast-moving projects. Add in static analysis, spec-based generation of tests, and/or fuzzers to get lots of reliability for free. Guess what? This method also scales excellently if the company has access to a huge pile of servers and engineers whose build system can automate all the checks with every submitted change.

Your idea that it has to be as ridiculous as process junkies is a strawman. A strawman that happens in a lot of places for sure but doesn't have to. Google can just take the few, easy-to-apply practices from high-integrity systems to get tons of benefit. It's the 80/20 rule for increasing assurance.

[hueving]

All of the processes you just described are antithetical to the processes I was referring to. Writing URL, design specs, etc is not the same thing is automated test generation, static analysis, and an API contract agreement. The thing you just described is exactly what I'm saying replaces all of the "on paper" crap that was taught as "software engineering" in schools as short as 4 years ago.

[losalamosal]

Or 40 years ago! I'm no fan of "process", but if you don't at least write down what you're trying to do (requirements) and some metrics for judging success, you open yourself up to two equally troublesome outcomes (depending on who's doing the evaluating): it's all a success or everything's a failure. Well written requirements and metrics (even brief ones) remove some of this evaluation ambiguity.

[kuschku]

Except, this is showing very much in reliability of Google, which is horrible.

Just look at Google Nest and their massive outage in December 2015, that’s usually enough to kill a company, and if Nest was independent, it’d have hurt them massively.

Their reliability is nice compared to competing websites, but compared to other infrastructure, it’s quite bad. Hell, I’ve seen 2 orders of magnitudes more Google outages than power outages in my entire life (combined 29min power outage vs. several days Google outage since '96)