A few months ago, I heard an interesting idea about the 2nd Worst Developer.  It's wrapped up in a simple statement:

... the quality of a software system is proportional to the skills of the second worst programmer

While at first pass, that may seem to be a silly statement, but here's why:

... everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.

On small teams with short projects and even shorter deadlines, this problem is multiplied.  Not only are you dealing with overlooked problems, but you're dealing with less-than-perfect decisions consciously made to "get it launched".  Now you have two problems that compound on each other... Brandon Savage covers this one well in "Paying Down Technical Debt".

But what if you had a way of preventing technical debt in the first place?

Well, obviously you've hired the top 1% of developers so how can we improve things without firing everyone and hiring new people?

Food for thought:

- Oddly enough, everyone claims to have hired the top 1% of developers...

- If you hired the people you just fired, what makes you think you can hire better people next time?

While many teams have solved this problem backwards and fowards, it's worth considering and working our way through again...

I do (and recommend) three things as a starting point:

First of all, as my friend and colleage Cal Evans (aka Mr April) says, every developer should read every commit message.  When I was with WhyGoSolo, at its peak, we had a team of 7 developers each working on different parts of the system which often interacted with one another.  Once we went into Feature Freeze for a release, we had a simple rule: every single commit had to be "blessed" by another developer.  It made sure that someone was looking over someone else's shoulder.  As a result, I believe only a handful of bugs made it into production.

Second, there are a handful of nifty things you can do with Subversion Commit Hooks as Matthew Turland shares.  While it doesn't seem like much at first pass, it's very handy to know there are zero syntax errors in the PHP within our repository.  That doesn't mean there are no bugs... but it ensures that any bugs are logical errors as opposed to typos.

Finally, I make sure to commit frequently to Subversion.  Every time I've fixed a specific bug, cleaned up some code, or implemented a new feature, I commit.  It means that at any given time, no matter how I've screwed things up, I can roll back to an old known-good version.  Even more importantly, by keeping every commit atomic, I limit the set of changed files to the scope of what I'm currently working on.

There is plenty of room for improvement in this scenario: Unit Test, Continuous Integration, etc...

Any other suggestions or creative things you've seen?