Where Developer Productivity Metrics Fall Short

Susan Hall
Slide Show

Gadgets to Make You More Productive

Must-have peripherals that Paul Mah considers to be excellent tools for helping you work more comfortably and efficiently.

In a piece at InfoWorld, Neil McAllister takes on IBM's scorecard system for measuring developer productivity. Big Blue's system awards points based on the volume and quality of the work they do. McAllister argues that such metrics just don't work.

 

IBM uses a source code analysis tool from Cast to compare code produced by IBM developers around the world with industry best practices. The system rates code for performance, security and complexity. Yet McAllister argues that's fine if all you care about is raw code production. But what about things such as documentation, mentoring and collaboration with other teams? What about evaluating existing code for reuse possibilities?

 

As McAllister points out:

A piece of code might be objectively "high quality" yet still cause problems in the long term. The code might be difficult for other developers to understand, reuse, or interface with. It might require extensive, unforeseen changes in other sections of the code base. It might place additional demands on the IT and operations staff who maintain the running application. Again, it's far easier to measure such things by intuitive methods rather than quantitative ones.

Meanwhile, Jim Highsmith, an executive consultant with ThoughtWorks, a company focused on agile software delivery, writes in a blog post that velocity is killing agility. He says too many companies are using velocity as a measure of productivity instead of focusing on customer experience and technical quality. He writes:

Agility is the ability to both create and respond to change in order to prosper in a turbulent business environment. It means we have to build and sustain a continuous value delivery engine, not one that bangs out many features the first release and then rapidly declines in ability thereafter. ... Our goal should not be productivity, but to "Design and deploy a great customer experience quickly - again and again over time." In order to respond to business, technology, and competitor turbulence in the market we have to focus on delivering a superior customer experience, building new features, and improving the delivery engine that allows us to deliver quickly each and every release cycle. ...


Business has moved from a world of periodic change to one of continuous change. In parallel to this, software development is evolving from project work (deliver software in a big batch and then maintain it) to one that is product oriented (deliver software in continuous releases). In order to drive behavior in the right direction we need to incorporate measures like value, delivery cycle time and technical quality metrics into our performance criteria.

McAllister argues that it all comes back to management:

For most other companies, however, it might be best simply to forget about the idea of measuring developer productivity and rely instead on tried and true methods. That's right: A highly effective, productive developer work force is often the result of high-quality, effective management. Unfortunately, nobody has developed a metric for that yet.


Add Comment      Leave a comment on this blog post

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.