Mad Dogs and Developers

Michael Vizard

One of the biggest challenges that any IT leader is going to have to deal with is managing developers. As a class of people, you might think that they are generally supportive of each other. But in reality, they all live by a set of ruthless meritocracy that borders on being vicious, especially with each other. The simple fact is that no developer, no matter how much experience they do or don't have, likes anybody else's code but their own.

Unfortunately, the only real way to develop quality software is to let developers review each other's code. The process may not be pretty, but then end result usually justifies the means, assuming that the original author of the code can stand up to the psychological assaults in the name of the greater good.

Assuming that it is unlikely managers will be able to introduce civility into the developer community at large any time soon, it's incumbent upon managers to at least bring some order to the chaos. That's what makes a new Klocwork Insight Pro developer productivity suite kind of interesting. Backed into the suite is essentially a code review process that is modeled on a social network. Rather than relying solely on in-person code reviews, managers can invite specific people to review code asynchronously in any order they choose. That may not seem like all that big a deal, but given the nature of developers, sometimes less direct contact can be a good thing. As one developer friend of mine once put it, he became a developer because he likes machines and cats, in that order. People weren't on the list.

Like a lot of developer tools, Klockwork also analyzes code to find errors. That level of automation will never replace the insight of a human developer. But it can help reduce the noise level by identifying simple mistakes that can be rectified before another developer ever looks at the code.

Getting developers to work collaboratively in teams is one of the hardest things that any IT manager ever has to do. Creating a framework to allow that process to take place with the least amount of friction possible, however, may be the best anybody will ever really be able to do.



Add Comment      Leave a comment on this blog post
Mar 17, 2010 8:03 PM Chris Bernard Chris Bernard  says:
You write, "But in reality, they all live by a set of ruthless meritocracy that borders on being vicious, especially with each other." This is not only grammatically incorrect, it's dubious at best. Then you write, "The simple fact is that no developer, no matter how much experience they do or don�t have, likes anybody else�s code but their own." This claim suffers the same fatal flaw -- it's an extreme position that is unsupported. Even one credible study would make these claims interesting. As a developer for 20 years, the code I like best is written by the open source greats. Reading it has made my code better. Reading my teammate's code often makes my code better. I am not unusual among people who love to code. If a developer really doesn't like anybody else's code but their own, that means they don't read much code, or they can't. This means they're probably weak and overly attached to their own code. This is simply unacceptable; it's unprofessional. Upgrade this developer. "Better" tooling is most often a convenient red herring -- a more comfortable improvement plan than dealing with the real problem. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.