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


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

High Performance Computing Linux Financial Markets
4/19/2010
New York City
Flagg Management

Informix User Conf.
4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

IBM brings Rational tools into the cloud
Fifteen Rational products for managing, developing and testing on clouds are now available...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

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