LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Metrics Are Essential


By Andrew Binstock
December 15, 2006 — 
In software development, metrics suffer from a reputation as tools of abuse. A recent post by Joel Spolsky in his famous blog, Joel on Software, reinforces this perspective by retelling a Dilbert-like story often trotted out when metrics are discussed.

It concerns a management consultant with no experience in software development processes (as Joel puts it, a “stunningly good-looking, bright, earnest chipmunk with 4.0s in Russian Lit from Harvard”) who, after getting project metrics from the company’s IT management and comparing them with an industry benchmark, points out that the developers are underperforming based on lines of code written per developer. After an expensive initiative to improve productivity, the developers learn to write more lines of code to do the same work—thereby meeting their new goals. The net result is a costly decrease in productivity to fulfill metrics-defined goals. Ugh!

Everyone can sympathize with developers being held to a nearly meaningless metric. Just because lit majors have abused metrics in the past, however, does not mean that metrics should not be employed. To quote Lord Kelvin, “You cannot manage what you cannot measure.” (The actual quotation is much longer and elaborate, yet most sources attribute this shortened version to him.)

My experience with sites that use metrics is that the first time they pull up their data, they have the same revelatory experience developers do when they first run a performance profiler on their code: The issues and difficulties are different from what they expected. This is the first step in a process that enables developers and especially managers to understand their processes. It is the first step to remediation.

Metrics fall into two broad categories: descriptive and prescriptive.

Descriptive metrics are the ones you want: They are objective data points about the status of code or of a project. They include, among other measures, code complexity, defect counts (ranked by defect severity), code coverage, unit tests written, time and cost metrics for defect resolution, etc. Many of these are obvious. Clearly, managers want to know defect counts. And developers should want to know code complexity. (You might ask why. The agile model uses “smells” to identify where code should be refactored. One of the most important smells to recognize and fix is code that is overly complex. Complex code is difficult to understand, maintain and debug. Metrics such as cyclomatic complexity objectively measure complexity and automate identification of code that smells. Clearly, some routines such as parsers are inherently complex and don’t lend themselves to much refactoring. However, running complexity measures on code helps identify routines that escaped detection but are in need of cleanup.)

Prescriptive metrics are the source of all trouble. They measure variance from a stated goal. This is where Spolsky’s “chipmunk” does his work. By saying, for example, that code coverage must be 80 percent, and that metrics will identify who is not meeting this target, the benefit of metrics is badly undercut. In fact, it breeds the wrong response. To quickly lift their codebase to the required coverage standard, developers might start writing unit tests for getters and setters—an established nonsensical activity—while continuing to write the former number of unit tests for their core work. This activity results in a net loss of productivity (as pointless tests are written) and a deterioration in the metric’s value, as the manager is now being misled by the data rather than illuminated. Prescriptive metrics don’t work because they encourage the wrong behavior.

This is not to say that metrics cannot be used to identify individual weaknesses and provide coaching opportunities. A coder who consistently turns in far fewer unit tests per KLOC is either working on some unusual code or is remiss in writing tests. A good manager will intelligently figure out (or know beforehand) which it is and then determine whether some remediation would be useful—either tutelage with a more senior developer or an in-person conversation. Used in this manner, metrics help the team, the manager and the developer.

A lot of this remedial work can be removed by publishing the metrics on a dashboard available to the entire team. (Agile precepts suggest that all team members are responsible for the entire project.) Developers will see for themselves where they fit with regard to their peers and then begin to bring up their numbers by themselves.

This self-diagnosis and self-correction is a terrific result of descriptive metrics—and one that validates their intelligent use.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.


Share this link: http://www.sdtimes.com/link/29882
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading