Christian Mackerprang has an interesting post to his site sharing some of his thoughts about why terrible code gets written by sane people - developers that know what they're doing but, for other reasons, write code that's a mess of anti-patterns and inconsistency.

What I discovered after some months working there [on a legacy Python project], was that the authors were actually an experienced group of senior developers with good technical skills. What could lead a team of competent developers to produce and actually deliver something like this? What I’ve come up is a list. These are some bad habits that even experienced teams can get into which will severely affect your end product, more than any static code checker or development methodology could rescue it from.

His list of reasons covers six of the reasons he sees for the "good people, bad code" situation happening:

• Giving excessive importance to estimates
• Giving no importance to project knowledge
• Focusing on poor metrics such as “issues closed” or “commits per day”
• Assuming that good process fixes bad people
• Ignoring proven practices such as code reviews and unit testing
• Hiring developers with no “people” skills

For each item in the list he briefly covers why it's a bad thing for your engineering group and references to other sources on good suggestions to fix the situation.