The PM IS one of the contractors. She knows our track record as a high-performance team, however she has lots of reasons that our previous experience does not apply:

a) it's a larger team
b) this product is customer facing
c) the PO is different

She says the performance discrepancies are generally due to the fact that the existing team has product knowledge whereas the contractors do not.

Now, this probably comes off like she has an agenda. I believe that she really tries hard to be unbiased, and you have to admit, when we're sitting there saying all the contractor programmers are lacking (except for the TA), it sounds suspiciously like "we don't like them because they aren't from here". That isn't the truth though- I was very stoked to add more people to the team. The thing was, we were all set to do a fully TDD application and knock it out of the park, and they came in with different ideas. We said "OK" and tried to adjust to new ways of doing things, but mostly we just created a mess of an app.

One point- the team I'm talking about was from a bank that was failed by the FDIC (had nothing to do with our software- I promise!) and we were hired to basically re-create the same software we'd worked on before (we worked on the back end, the contractors worked on the front end- but of that team only the TA, PM and one QA remain- the rest of the contractors are all new). When I told our current PM that there was a reason the people from the old team were chosen, her immediate response "Because you guys had the most product knowledge", not because we were good at what we did (which my manager- at both locations- assured me was the reason)

The difficult part of all of this is that our TAs are not involved enough in the code to truly know the ill effects of all that's going on, while I am officially at equal rank with all of the other developers. I do have the ear of the TA on our end, and the PM respects me enough to ask my opinion (and try to do things the way I suggest). But while both TAs agree with my assessment and the PM is willing to listen to me, it's hard to REALLY take disciplinary action. There's always a feeling of "well that's YOUR way, but that doesn't necessarily mean it's the ONLY way."

I don't know how many times I've been asked "is TDD necessary for writing quality software?", to which I always reply "absolutely not, but it's one really good way of getting there". The problem is, if we aren't doing TDD, we need to be doing other things that give us the same benefits TDD gives us.

I will pass this idea along to my manager- I think this is definitely something we could implement. The question is, who goes through and assigns the reasons for the bugs?