yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
Cloud Expo & Virtualization 2009 East
Smarter Business Solutions Through Dynamic Infrastructure
Smarter Insights: How the CIO Becomes a Hero Again
Windows Azure
Why VDI?
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun's Incubation Platform: Helping Startups Serve the Enterprise
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Change Is Good!
The trend toward per-developer metrics in the software development process

In an article in the October edition of the FTP Webzine "Upside" Peter Varhol laments the trend toward per-developer metrics in the software development process. "Individual developer data is stored and available to be manipulated in less than honorable ways," he says, "and there are people in enterprises who know how to take advantage of such information for their own purposes."

Yes Peter, those people are called "managers" and their purposes are called "management." It's what they are supposed to do.

It's high time this industry grew up and, I'm afraid, growing up means opening up and letting managers see what developers are up to on a day-to-day basis. Earlier in his piece Varhol talks about the "bubble world" that developers have created for themselves by encouraging the view that software development is mysterious, highly complex, and technical.

Peter Varhol isn't the only person who seems change-averse in this respect. Other industry commentators have weighed in on the issue too. Linda Westfall is president of The Westfall Team, a consultancy that specializes in software metrics and software quality engineering training. "Don't measure individuals" she says in her 2005 paper on software metrics. "The state-of-the-art in software metrics is just not up to this yet." To be fair, she goes on to explain that what she's really talking about is individual productivity metrics measured in "lines of code per hour." True, that wouldn't seem to be a useful metric. But that doesn't invalidate the idea of looking at any metrics on a per-developer basis.

Sam Guckenheimer of Microsoft, in his book Software Engineering with Microsoft Visual Studio Team System, says: "Using metrics to evaluate individual performance is horribly counterproductive."

Joel Spolsky says, "FogBUGZ does not provide individual performance metrics for people."

So what's the deal? Why is everyone so against the idea of measuring the performance of individual developers? After all, in just about any other industry, you'll find per-individual metrics being applied without so much as a second thought.

Take sales for example. Culturally, you're unlikely to find any two groups in a company more diverse than sales and software development. But actually, these two departments have more in common than you might think. Both work in teams, but are highly dependent on the performance and contribution of individual members. In fact, oftentimes, the contributions of one or two "superstars" overshadow the contributions of everyone else put together. Both work for extended periods of time to deliver an outcome. And both are notoriously difficult to manage!

But there's one significant difference between these two groups. Sales teams, especially inside sales teams, have clear targets, not just for the outcome (dollars and cents) but also for their behavior on a day-to-day basis. I'll always remember one of the most successful sales managers I've ever known early in my career telling me the secret to her success, "Manage behavior; reward results." In the case of the inside sales team, the way we manage behavior is by looking at call metrics: the number of dials, total talk time, average call duration, etc. These are measures of the desired behavior of the team.

So, what's the desired behavior of the development team and what metrics can we put in place to measure it?

Well, Linda Westfall is right about one thing: we don't simply want to measure lines of code per hour. That's not a measure of productivity; it simply encourages verbosity! But perhaps we do want to measure compliance to coding standards. We might also want to measure unit test coverage and density, code complexity, reuse effectiveness, and defect rates.

The important thing is that we should think carefully about what behavior we want to encourage and then put mechanisms in place to capture the metrics to track our progress. But here's an important and rather subtle distinction between different types of metrics. Often, the thing that makes metrics, especially per-developer metrics, seem bad to so many people is that they when they think about metrics, they're thinking about prescriptive metrics. Prescriptive metrics carry with them a target level of achievement that defines success. The problem with prescriptive metrics is that they encourage slavish devotion to achievement of just that metric, sometimes at the cost of rational thought.

Joel Spolsky again: "As soon as you start measuring people and compensating people based on things like this, they are going to start optimizing their behavior to optimize these numbers, and not in the way you intended."

Coming back to our sales team example, if you just set a target for total talk time, without measuring the number of key contacts that the salesperson talks to, you encourage the wrong type of behavior - talking at length with someone who's never going to buy anything, for example.

The same thing applies in the software development world. It's generally accepted that 100% code coverage for unit tests isn't a good objective. Not only is it potentially time-consuming to squeeze the last few percentage points of coverage out of an application, but this is also the sort of thing that could really encourage the wrong behavior. Exception handlers are usually the hardest parts of the application to unit test. So what's the easiest way to increase your coverage percentage? Get rid of your exception handlers! That way you don't have to figure out how to test them.

Contrast that approach with the concept of descriptive metrics. As the name suggests, these are metrics that we just report, without any set notion of what's a "good" number in absolute terms.

To pick up the sales team example again the number of calls per day and total call time are descriptive metrics. We don't reward the team based on these metrics; we've already seen how that can lead to counterproductive behavior. However, if we observe a significant drop in sales by an individual then these metrics can provide a clue to the cause of the problem. Similarly, if a developer has consistently higher bug rates than his or her colleagues and lower unit test coverage then it's clear what action needs to be taken to bring that developer up to standard.

Here's the thing. This software development industry of ours is still pretty young. We're still figuring some of this stuff out. Blindly trying to apply manufacturing-style metrics to the software development process won't work. They are two different processes, and should be treated as such. But that doesn't mean we shouldn't be striving to apply some metrics and working hard to figure out what the metrics are and how to manage them.

So, to Mr. Varhol's target audience I say fear not. Embrace change. Don't stick your head in the sand and say metrics are a bad thing. Let's work together to figure out what we can measure, and how we can use those things to manage ourselves better. After all, our customers deserve better.

About Nigel Cheshire
Nigel Cheshire is CEO of Enerjy Software, a division of Teamstudio Inc. He oversees product strategy and has been driving the company's growth since he founded it in 1996. Prior to founding Teamstudio, Inc., Nigel was co-founder and principal of Ives & Company, a CRM solutions consultancy. He holds a Bachelor of Science degree in computer science from the University of Teesside, England.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

In an article in the October edition of the FTP Webzine 'Upside' Peter Varhol laments the trend toward per-developer metrics in the software development process. 'Individual developer data is stored and available to be manipulated in less than honorable ways,' he says, 'and there are people in enterprises who know how to take advantage of such information for their own purposes.'

Your Feedback
Java News Desk wrote: In an article in the October edition of the FTP Webzine 'Upside' Peter Varhol laments the trend toward per-developer metrics in the software development process. 'Individual developer data is stored and available to be manipulated in less than honorable ways,' he says, 'and there are people in enterprises who know how to take advantage of such information for their own purposes.'
Latest Cloud Developer Stories
The precious oil is extracted from the seeds of prickly pear cactus plant. After taking out the seeds from the fruits, they are adequately dried and then cold pressed to obtain the oil. Indeed, the prickly seed oil is quite expensive. Well, that is understandable when you conside...
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering cons...
ScaleMP is presenting at CloudEXPO 2019, held June 24-26 in Santa Clara, and we’d love to see you there. At the conference, we’ll demonstrate how ScaleMP is solving one of the most vexing challenges for cloud — memory cost and limit of scale — and how our innovative vSMP MemoryON...
Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, vi...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers