Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.
In general, the answer typically involves formal specification and formal methods that check the code against these specifications, combined with testing and coding standards that result in analysable code.
You might want to look into coding standards for C and special languages like Ada (like C, but less writeable, more readable with strong types) and Esterel (deterministic multithread scheduling). Seriously, Esterel is probably the coolest thing you'll read about this week.
There's also various specification languages for multithreaded behaviour, which allows you to analyse your programs behaviour using software tools, for example SPIN[0].
If we're all creating giant balls of mud because the demand is for giant balls of mud done quickly, then we never learn how to craft beautiful software.
It's unfortunate, and it's sad to say I'm often part of it at some level (but I fight it dammit!).
FDA requirements mostly target the SDLC: risk analysis, change control, documentation, v&v, &c. Companies are afforded a surprising amount of flexibility in implementation. Basically, you must have a documented process that you follow, but you're left to your own devices in creating the process. Deviations from voluntary industry standards (e.g., TIR 45) is permissible since they're not specifically required. The DoD, aerospace, and automotive industries have in comparison far more detailed and strict regulatory requirements.