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