When you need to write software that works, you take a fscking course in Software Engineering. You learn what your code is doing and you make it work. I'm not saying it's "easy", but I don't believe it's "hard". I haven't been around enough to be sure, but I think they're pushing the "normal coders are frivilous twenty-something-year olds" line a bit hard.
You can make software work, but the reason it often doesn't is due to poor management and budget constraints. With the tech boom, perhaps people got used to too much, too quickly. Writing software takes time and money, and I get the impression that just doesn't happen nowadays. Apparently noone has the time to do proper requirements analysis, then follow this up with ERDs/DFDs.
You can write robust code, so long as you keep some things in mind. Heck, let's make that one thing: paranoia.
Never assume anything about the data that's coming in (and what happens to it once it's out of your hands). Which leads us to the next bit, which is being able to deal with ANY data that that does come in (or gets lost).
We have tools to help us do this. Maybe they're expensive, but you can use them, and they can assure you 100% (and show you the proofs!) that your code cannot fail, assuming the system behaves in a predictable manner (ie. CPU keeps running and code is read one line after the other, sorta thing).
Commenting: Removes ambiguity. The big bonus is obviously in a team environment. That way, John doesn't need to ask Jim what $xyz refers to. He already knows.
>>9 management's fault: Well, that's the ego-tripping side. I admit it, I'm not a developer, I'm a bright-eyed, idealistic, naive young-un. Neither mgmt. nor coders can be absolved completely from blame. But as we've already agreed, everyone has to work together.
Static analysis: what I was referring to here was actually not code analysis but logic analysis. We were taught at uni with the "B toolkit" (don't know if you've heard of it, I don't know how widespread it is). You specify your system using Abstract Machine Notation (AMN) and it whirrs its gears and checks that all the logic is bulletproof. Many people in the subject hate it, and I can see why, but by the end of the course, it had really grown on me, and I have a certain respect for it now.
What I meant by 100%-perfect code was that the toolkit can apparently (I never used this feature) write the code for you (presumably C or something). Not all of it, obviously, but the core logic.
And yes, I agree it's still not perfect. The system may be perfect, but the working environment isn't.