Blog

Friday Summary, August 1, 2014: Productivity Metrics edition

By Adrian Lane

I read Jim Bird’s blog consistently because he talks about stuff that interests me. He has a ton of experience and his posts are thought-provoking. And every couple months I totally disagree with him, which makes reading his stuff all the more fun. This week is one of those times, with Devops isn’t killing developers – but it is killing development and developer productivity. I think Jim flat-out misses the mark on this one.

  • The metrics we use to measure productivity are broken. Always have been – stuff like number of lines of code and velocity. Software development metrics have always been crap. Do you really believe more code is better? Isn’t the goal to deliver quality products which include robustness, satisfaction of requirements, security, and so on? Measurements like velocity are made-up and irrelevant to our real needs. They don’t actually tell us what productivity is – all they do provide a trending indicator which sometimes tells us a change we made to the process is having an effect. If we had something better we would use it, but most development metrics are surrogates for real measures because we don’t have any good yardsticks for producing quality code.
  • Which leads to the second point: DevOps spotlights just how broken these metrics are. It is specious to consider developer productivity as going down when the focus of developers and IT has changed to include test orchestration, deployment, and systems management. Developers scripting Chef, Puppet, Bamboo, or whatever are still working productively. Orchestration scripts are code – they are not wasting time handling operations. Writing tests scripts is still work (which developers typically don’t like) and part of the job. The goal is to automate tasks so you don’t need to manually repeat them over and over.
  • DevOps is not the same thing Continuous Deployment. Continuous Deployment is part of it, but not the whole enchilada.
  • DevOps allows developers to be more responsive to customer requests – not because they are chained to a pager answering support calls, but because automation and the infrastructure-first approach enables them to be. Sure, you can screw up priorities and clog the swim lanes with the wrong tasks, but that is a management issue – not a DevOps problem.
  • I agree that not all developers like having to assume more programmatic orchestration of IT operations, and they aren’t necessarily good at it. But the key shift to take note of is that IT staff had better learn to program, or they will have a tough time finding work. The key to DevOps is automation, which means code and scripts… which is why IT needs more developer-centric skills.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

No Related Posts
Comments

If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.