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


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

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

Guest View: The future of quality lies in productivity


By Adam Kolawa
May 1, 2008 — 


Managers push quality on developers the way parents push vegetables on their children. Given a choice, most kids won’t touch a lump of spinach sitting on their dinner plate. But if you blended pureed spinach into the chocolate brownies for which they always reach, your children would get the intended nutrients without your ever having to utter, “Eat your vegetables.”

During the past 20 years in the software industry, quality initiatives have come and gone, along with countless attempts to find a silver-bullet tool that would deliver quality with the click of a button. Unfortunately, there is no silver bullet. Some ideas work in theory, but few have succeeded in practice.

The major problem is that when managers try to improve quality, they unintentionally pile more work on time-starved developers. Quality tasks are introduced in such a way that they require developers to adjust their tried-and-true workflow to take on additional work. Not surprisingly, this usually isn’t well received. If developers don’t believe that learning and applying this new practice will be worth the effort, by relieving them of tedious tasks to allow them to focus on the creative work they enjoy, the practice eventually will decay. The developers probably won’t reject the new initiative outright; they will simply do it less and less until they stop altogether.  

We push these well-meaning quality initiatives without considering their effect on productivity. Quality increases productivity, we assume, but that’s not the case. If you want to introduce a quality initiative, do it in a way that doesn’t disrupt or slow the normal workflow. Otherwise, there’s little chance of achieving a sustainable quality process.

A good workflow can make or break a quality initiative. For example, assume that someone delivers a mandate: “All code must be peer-reviewed.” If the development manager responsible for implementing the peer code review interprets that as meaning, “No developer can check in code before it is reviewed,” he is creating a tremendous roadblock in the developers’ natural workflow. This is a prime example of a quality initiative that would hurt productivity.

This process is illustrated in the following figure:




Now, the developer must do a lot of extra work before adding code to source control. Even with an automated infrastructure managing key tasks, the developer has to remember to initiate the process that identifies code ready for review and enter a description of the intended changes.

Without an automated infrastructure, the developer also must identify the code that needs to be reviewed and organize it into logical packages. He has to distribute the review packages to the appropriate reviewer, notify the reviewer, and monitor the review status until closure—and perhaps even remind the reviewer of the pending review.

This is tedious and time-consuming work. As a result, developers will probably try to follow this process initially, and project progress will likely slow to a crawl as a result of the additional work and the new roadblock. Once they realize that, reviews will become less frequent. Eventually, peer code reviews will be nothing more than a bad memory.

A better approach would be to interpret the mandate as, “I don’t want to have unreviewed code in any application when it goes to production,” which would allow code review to occur after check-in. This means that code in the source control system will not be 100% reviewed all the time. Code will not be reviewed the minute it is checked in; it might take several days. But this is a small trade-off for the more productive workflow that results.

By implementing automation between the developer and his code check-in, the mandate becomes much less disruptive to development. The more tasks get automated, the better. The burden on the developer is reduced because he’s not forced to perform additional work. He merely checks in the code as normal. The only added work for the team would be the actual peer review—a creative process that cannot, and should not, be automated.

This less disruptive process is illustrated in the following figure:



What’s important is that this type of setup actually doesn’t increase the amount of work, but rather reduces it. How? Because the code review actually enables early error detection. That, in turn, cuts the length and difficulty of debugging, which typically consumes tremendous development resources.

The interesting thing here is that the greatest value is achieved by focusing on productivity, not quality. Focus on quality without considering productivity and you likely will end up with minimal to no quality improvements, slipped schedules, and a disgruntled team. But focus on productivity by helping the team work smarter, and the team will deliver better software faster.

Adam Kolawa is the co-founder and CEO of Parasoft, which sells software testing tools.


Related Search Term(s): Management, software development


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading