Steps 2 Through 4

By John McCormick  |  Posted 2004-03-05 Print this article Print

Software creation is increasingly a collaborative process. That has led to systematic approaches of reviewing the quality of team-created applications.

The Capability Maturity Model, developed by the Software Engineering Institute at the request of the Defense Department, establishes whether a given organization has mastered good software development practices. These include the reliable setting of specifications; proper means of evaluating code that has been created; the ability to set and track internal performance metrics; and consistently finding better ways to develop software. Organizations work their way up five levels of maturity model team certification.

Parasoft’s Kolawa says a software professional also ought to be certified in a particular industry, be it finance, pharmaceuticals or aerospace. If software quality is going to take any leap forward, Kolawa says, “this type of certification of specialty will have to happen.”


As exemplified by the unexpected fatalities that resulted from the way radiation machines were used in Panama, developers never can anticipate fully how their applications will be used. Yet too often developers don’t spend the time and energy needed to find out what users really want and need.

McGraw calls this the “sneaky, dirty little secret of software development.” Even in conventional business applications, the developer philosophy often is: “If they don’t tell us exactly what they want, we’ll just give them something,” he says.

The starting point for fixing this software-development flaw is simple: a precise list of what a new program is supposed to do that can be agreed upon by the people developing the software and the people who will use it. Then teams must double- and triple-check the code they create to make sure users can’t ask it to do tasks that aren’t anticipated or cause unexpected conflicts in calculations.


Building software requires engineering as serious as the kind required for high-rise offices. Just as there are building codes for skyscrapers, so now are serious developers following code codes.

In its Code Conventions for the Java programming language, Java’s progenitor, Sun Microsystems, clearly delineates the number of code statements—known as “declarations”—that should be written per screen line (one) and how long each line should be (not more than 80 characters). These conventions recognize such basic facts of code-writing life as how computer terminals “wrap” lines of characters that appear on their screens. The conventions also outline how to clearly name files and how to insert helpful comments into lines of code.

Code conventions are important because they make the code easier to read—and maintain—by people who haven’t worked on it.

Jack Ganssle, an engineer whose Ganssle Group advises companies and developers on how to create high-quality software, acknowledges that “a lot of software engineers think that this [discipline] is totally worthless—a way to depress their creativity.”

But, he notes, “they’re wrong. If the source code is not readable, [if] it’s not absolutely clear, how do you think you can possibly audit it, understand what it’s doing and look for errors?”

Next Page: Test, retest and establish a seal of safety and dont buy problems.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel