About 10 years in the past, I wrote a weblog put up referred to as “Can we measure developer productiveness?” In it, I mentioned the various goal makes an attempt that had been made to do it — traces of code, perform factors, and so on. I additionally proposed some subjective measures. Nonetheless, the conclusion was that regardless of the wishes of KPI-loving managers, there was no viable method to measure the productiveness of a person software program developer.
I point out this text revealed 10 years in the past as a result of issues have modified considerably within the years since. After I wrote it, Git and Mercurial had been each distinguished and fashionable software program supply management techniques. I used to be a software program supervisor on the time, migrating my group off of Visible Supply Secure from Microsoft, and we determined to go along with Mercurial as a result of it was way more Home windows-friendly.
We picked the incorrect horse as a result of, within the years to come back, Git would turn out to be the de facto normal for model management. In consequence, a cottage trade has arisen round Git repositories. GitHub is a big enterprise for which Microsoft paid $7.5 billion. Many corporations now present metrics round your code in Git. And plenty of of these corporations purport to measure the productiveness of software program builders.
Gimme metrics
If we concede that it’s attainable to measure developer productiveness (a proposition that I’m not utterly offered on), we then should ask whether or not we ought to do this.
The need to take action is definitely robust. Managers need to know who their finest builders are, and so they need metrics that can assist them at efficiency analysis time. HR desires to have the ability to doc efficiency points. CEOs need to know that the cash they’re spending is getting used successfully.
Even when you use new instruments to measure particular person developer productiveness, these metrics will seemingly be gamed. Traces of code is taken into account a joke metric today. “You need traces of code? I’ll provide you with traces of code!” Is variety of commits per day or common time to first PR remark any completely different? In the event you measure particular person builders on these metrics, they are going to most positively enhance them. However at what value? Possible at the price of group productiveness.
An outdated CEO of mine used to say that software program improvement is a group sport. If particular person builders are measured towards one another on any metric, they are going to begin competing with one another, particularly if cash and promotions are on the road. And a bunch of individuals competing towards one another will not be a group.
It’s groups, not particular person builders, that get issues completed within the software program enterprise. Software program improvement is attention-grabbing in that regard. The precise coding is usually finest completed by people in deep thought, however the work that occurs earlier than and after the code will get written contributes drastically towards making issues profitable.
Measure the group
A improvement group discusses the design and implementation of a given mission earlier than any code is written. When the person builders write the code, it’s typically with the assistance of teammates who reply questions and supply perception. All group members assessment and approve what is completed throughout code opinions. Everybody works collectively to make issues occur.
The energy of the group is every particular person member. The energy of every member is the group. —Phil Jackson, NBA coach
That’s the reason, as a substitute of measuring particular person developer productiveness, it’s group productiveness that must be measured. Builders working collectively as a group, pushing towards a typical objective, is what managers actually need.
Groups know that in the event that they enhance their group metrics, they enhance their success. Groups that may see the advantages of specializing in the suitable issues and maintaining a tally of the suitable metrics will enhance. Groups need to enhance their productiveness. They need to get higher. They need to ship. Measuring team-based metrics helps them do these issues.
10 years in the past, I requested if we should always and even might measure developer productiveness. However I used to be asking the incorrect query. Particular person builders are solely as robust as their groups. Correctly measuring group metrics leads a group towards higher outcomes and higher software program. As an alternative of measuring people, we should always encourage our groups to construct software program higher and quicker by measuring what they do collectively.
Copyright © 2022 IDG Communications, Inc.
