A coworker relayed the following problem, let's say it's fictional to protect the guilty:
A team of 5-10 works on a project which is issue-driven. That is, the typical flow goes like this:
a chunk of work (bug, enhancement, etc.) is created as an issue in the issue tracker
The issue is assigned to a developer
The developer resolves the issue and commits their code changes to the trunk
At release time, the frozen, and heavily tested trunk or release branch or whatever is built in release mode and released
The problem he's having is that a couple newbies made several bad commits that weren't caught due to an unfortunate chain of events. This was followed by a bad release with a rollback or flurry of hot fixes.
One idea we're toying with:
Revoke commit access to the trunk for newbies and make them develop on a per-developer branch (we're using SVN):
Good: newbies are isolated and can't hurt others
Good: committers merge newbie branches with the trunk frequently
Good: this enforces rigid code reviews
Bad: this is burdensome on the committers (but there's probably no way around it since the code needs reviewed!)
Bad: it might make traceability of trunk changes a little tougher since the reviewer would be doing the commit--not too sure on this.
Update: Thank you, everyone, for your valuable input.
I have concluded that this is far less a code/coder problem than I first presented. The root of the issue is that the release procedure failed to capture and test some poor quality changes to the trunk. Plugging that hole is most important. Relying on the false assumption that code in the trunk is "good" is not the solution.
Once that hole--testing--is plugged, mistakes by everyone--newbie or senior--will be caught properly and dealt with accordingly.
Next, a greater emphasis on code reviews and mentorship (probably driven by some systematic changes to encourage it) will go a long way toward improving code quality.
With those two fixes in place, I don't think something as rigid or draconian as what I proposed above is necessary. Thanks!