Re: We already have the techniques!
Re, race conditions, management pressure, and specifications:
As a matter of fact, I come from a background of mixed software and hardware. One of my bosses was from the Intel 80386 design team. Flat out, if you have complex race conditions, then either get someone who understands them, or use designs that avoid them. Race conditions are well-solved! Threading and concurrency are well-solved! There are many books that explain this stuff, and explain it well.
For management, yes, I am quite familiar with the "ship it now" idiots. I just left a company where that was the mantra, and it resulted in a garbage product that was repeatedly rejected by customers. Literally, the customers would demand their money back because the product actually didn't work, and the management never decided to ship a quality product. If you work in an ethics-free company, then the only thing to do is get out of there. Run. The management just wants to screw over everybody, and then fold and run when trouble comes.
As for the spec, yes, part of the "engineering" is getting the spec right, as in, a coherent and correct spec. I had a temp job at an OS company in Redmond, WA, where the spec was, literally, the names of some structure fields, and nothing else. They claimed that a full spec wasn't "buying" them anything, so they didn't do it. The team had some of the worst code monkeys I've ever seen.
The source of truly bad software is people who don't give a s***!! Managers who know nothing are managing programmers who lie out their ass. "Oh, hey, I'm managing!" "Oh, hey, I wrote code that compiles!" That creates a living hell for anyone who actually cares about quality. You can write up hundreds of bugs, but the product will get shipped anyway, because something has to go out the door.