Succeeding with mediocrity

One of the criticisms of engineering practices like XP (and Agile for that matter) is that success is only really possible with strong, experienced developers.  But is it really possible to succeed with mediocrity?

In my experience, teams have a certain amount of potential.  Conditions can be optimized to maximize their potential, as well as grow it.  But mediocre teams will only produce mediocrity.  No process, nor tool will change bad developers into good ones.  Can anyone expect a mediocre wood craftsman to produce good furniture?  The most you can hope there is that the chair won’t collapse when you sit down, or a nail won’t poke you in the ass.

It’s also true that strong, experienced developers are more likely to succeed no matter what the process.  But given a strong team, I’d rather continuously improve the process with regular feedback to improve my chances, rather than assume that a strong team will automatically succeed.  I’ve been on the other end of that stick, on a strong team that failed because of bad process decisions.

I think we have to move past the idea that success is attainable with mediocrity.  The way I see it, the most we can hope for in mediocrity is to not fail, which is quite different than success.  On that note, check out Jeremy Miller’s article on continuous design in this month’s MSDN magazine.  If your team is not able to achieve this kind of design, it’s probably a good idea to start lowering expectations now.

If it’s part of our company’s business model to need highly successful software projects for the company to succeed, the company would need to decide to either a) hire/nurture developers if software is the company’s core competency or b) outsource to smart people.  For either a) or b), a company has to be able to hire folks that have both the desire and capacity to become strong performers.

I think, as an industry, the pool for those types of folks is quite small.  On the other hand, many other disciplines have created professionalism where none existed before, so software development doesn’t need to be any different.  So how do we get there?  Professionalism should be the accepted standard of employment, not what TLA tools you’ve learned recently.  Know WCF?  Who cares, can you make the informed decision to know when RPC is applicable.  Anyone can read a book and sling software, but creating maintainable code when it counts is something else entirely.

Software development is still a young industry, and we are still figuring out how to maximize the value of our efforts.  But I don’t think we need to accept mediocrity as the norm, our customers demand better.