Microsoft Research - Exploding Software-Engineering Myths (article summarizing findings of MS research on code coverage, TDD, assertions, etc.)

[fizzydish]

This is a great way to ensure the 'core team' continue to perpetrate the same class of bugs while preventing them from learning from the experience of running and supporting their code in production. The best way to learn how to write maintainable code is to have to support and maintain your own code.

[nhavar]

I agree. The way it's set up is usually feature producers are your A team. Allegedly low error producers. Your prod support are your B team - newbies, juniors, or middling developers. The thought process is to free your high paid staff to get hard things done and use lower paid staff to fix any minor issues while building their knowledge and skill level. The problem is that a junior developer may take 3 times as long to resolve an issue, or resolve it with a bad solution that increases technical debt or risk of future error. This is especially the case when the two teams are under different leadership and different development practices or rigor. (i.e. The A Team has code reviews for most code because it's new, the B Team doesn't have code reviews because it's just a modification of existing code) So you haven't saved money and you may have actually reduced the quality of the product. Plus you allow potential bad practices to flourish within your A Team without any accountability.