[jrp]

Developing reliable, high-quality software, especially for a complex, hard real-time embedded system is massively labor intensive and very much depedent on the knowledge and skill of each of the software engineers. It's not too much of a generalization to say that one lousy developer can jepordize the reliability and reputation of an entire system.

I've been in this business for almost 20 years and hate to say that most developers write pretty poor quality code. I've had to throw away a lot of it, not because I couldn't understand it, but just the opposite. I knew all too well that it deviated so far from good software engineering practice that no amount of tweaking and patching would ever make it reliable or maintainable. In those cases, it usually made more sense to rewrite it. Of course, that's a much easier decision to make on a small project than something the size and scope of the F22 avionics code.

[Spruce]

The challenge is when to re-write. I have always based this on a Kludge/code ratio. When Kludge gains a foothold and becomes the standard, you re-write. It would seem they have hit that wall.

[mikegi]

I've been in this business for almost 20 years and hate to say that most developers write pretty poor quality code.

Funny, isn't it? It always seems to be the other guy who writes sh*tty code. I pity the poor soul who had to take over my code!