Yesterday at Domo’s Domopalooza conference I had the opportunity to listen to Billy Beane, the GM of the Oakland Athletics MLB organization, and the subject of the 2003 book and 2001 film Moneyball. Beane spoke about how their organization used hard data to produce winning baseball teams with a drastically lower budget than some of the other winning MLB teams. I found the session fascinating and it got me thinking about the applications in hiring great software developers.

I’ve often thought that the way we hire software developers is not very effective. We try to gauge a developer’s talent by giving them little problems to solve: sometimes these are puzzles and brain-teasers, though these seem to be growing less common, and other times they are little programming problems to be solved on a whiteboard. While these can be fun, and even instructive, I don’t think they result in a good hiring decision.

I am intrigued by the idea that instead of little exercises (similar to a scout watching a baseball player in high school, or a tryout), we need to have some hard data to base our decisions on. The big difference between professional sports and software development, though, is that athletes have their performance constantly measured and recorded. MLB is full of stats: wins, losses, on base hits, home runs, stolen bases, etc. With that data you can find out interesting things about the game, such as the fact that stolen bases contribute very little statistically to whether a game is won or lost.

While software developers don’t have performance measurements that are public, there are ways of measuring that performance: bugs written, lines of code produced, bugs resolved, etc. If we had statistics like these that were public, then maybe we would have a better way of finding and selecting the right developers for our projects. But within our own organizations we could keep track of these statistics and use them to manage our employees after they were hired.

But many software developers are now starting to become involved in social programming. Many of us are participating in code retreat days, programmer meetup groups, hack nights, open source projects, etc. Quite a few of us are even putting our side projects out in the open on sites like github or codeplex. What if we could process all that data and get statistics about what good programmers look like, and find ways to measure a programmer’s talent in a real way?

Of course, there are a lot of intangibles that still probably need to be interviewed for. It’s not worth hiring somebody that no one gets along with just because they have some skills. But if you could weed out the people who don’t have what you’re looking for, wouldn’t you be miles ahead in the interview process?