I've never managed a developer or development team directly, but for years now I've been a primary "non-tech" stakeholder for the sites that I've helped launch and operate. So, I know enough to poke around in admin tools and find evidence of data corruption or to write oversimplified business logic equations on a whiteboard-you know, stuff that really irritates developers.
So, I was particularly interested in Mike Vizard's post over at our CTO Edge site this morning about a new collaborative code review product that proposes to, among other things, take some of the edge off what can be a pretty uptight process.
In describing developers, Mike writes:
" 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."
My own observations are not entirely dissimilar, although I might not call the culture borderline vicious, unless it comes to late-night Counter-Strike tourneys on the company LAN.
I'll put it this way: To have a productive conversation with many developers, you first have to repeatedly prove that you are, in fact, able to count past 10. You also have to get it through to them that if their application reports a bunch of SQL lookup errors, it's probably not because of user error.
I feel your pain, QA and PM guys.
So I, too, am in the corner of anything that makes code review easier, from a people-management point of view.
I thought I'd get a more qualified opinion, so I chatted with our own VP for development here at IT Business Edge, Steve Hardin (no relation), who is as collaborative, business-savvy and downright likeable a developer as you could hope to work with.
Steve's first impression was that adding more advanced collaboration tools than can be found in typical source control system might be good for enterprises, but not so much for smaller businesses or development teams. Makes sense to me. In smaller shops, it's inherently harder to call in code reviewers from other units, so a toolkit to "Facebook" the process clearly would have diminished value.
I was more interested in the personal resistance to code review, which Steve said is certainly real. It's understandable -- nobody likes to be criticized or edited. Keeping code review in a virtual environment, as opposed to face to face, seems to be an idea everybody can get behind.
Most of my and Steve's conversation focused on code being reviewed during an actual dev cycle as a QA measure for launch, as opposed to an ongoing audit of code already in production, which I believe is what Mike is describing as the "asynchronous" review process-reviewing any block of code at any given point in time -- which is the focus of this new toolset.
Steve, reasonably so, said that review of any production code by someone not familiar with the pressures and constraints of the project is always going to be met with the most resistance.
I'd say that's true, but by the same token, that's also in many ways the most valuable feedback you can get. So any tech that can grease the code-review wheels with collaboration, anonymity or personal distance seems like a pretty good idea to me.
It's an interesting twist on the typical evangelizing about collaboration, which assumes that all employees are chomping at the bit to collectively improve product and business processes, if only there were a tool to connect the right people and data. Collaboration sounds like a blast, until somebody tells you your trend analysis is weak or your code is buggy. And criticism is inherent to any real collaborative process.
Tech can be a great tool for facilitating collaboration, but company culture and management intiative are still the engine for it.