Scribd
Upload
68 views

How To Build Reliable Code

The document discusses how to build reliable code. It outlines that while tools and techniques can help, the most important factor is how well a project is managed. A development team must have a clear design, constantly test their code, and be willing to sacrifice speed for reliability. The article then provides several strategies to help build reliable software such as fighting for a stable design, cleanly dividing tasks, avoiding shortcuts, using assertions liberally, and relying on fewer programmers.

Uploaded by

Carlos Sabido
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
68 views

How To Build Reliable Code

The document discusses how to build reliable code. It outlines that while tools and techniques can help, the most important factor is how well a project is managed. A development team must have a clear design, constantly test their code, and be willing to sacrifice speed for reliability. The article then provides several strategies to help build reliable software such as fighting for a stable design, cleanly dividing tasks, avoiding shortcuts, using assertions liberally, and relying on fewer programmers.

Uploaded by

Carlos Sabido
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

How to Build Reliable Code

December 1995 / Cover Story / How Software Doesn't Work /


How to Build Reliable Code
Oliver Sharp

The first thing to understand: It is hard to build complex software that works well.
In the search for salvation, or what software engineer and author Fred Brooks calls
the silver bullet, many people look to models, techniques, and tools. Once upon a
time, the solutions were structured programming and high-level languages; now,
they're applications builders, componentware, and object-oriented-programming
(OOP) techniques. However, evangelists for all these solutions ignore an
uncomfortable truth: Reliable software can be written using gotos and assembly
language, and truly dismal code has been produced using impeccably modern tools
and techniques.

The reality is that one factor completely dominates every other in determining
software quality: how well the project is managed. The development team must
know what code it is supposed to build, must test the software constantly as it
evolves, and must be willing to sacrifice some development speed on the altar of
reliability. The leaders of the team need to establish a policy for how code is built
and tested. Tools are valuable because they make it easier to implement a policy,
but they can't define it. That is the job of the team leaders, and if they fail to do it,
no tool or technique will save them.

One reason that quality often takes a backseat is that it is not free. Reliable
software often has fewer features and takes longer to produce. No trick or
technique will eliminate the complexity of a modern application, but here are a few
ideas that can help.

Fight for a Stable Design

One of the worst obstacles to building a good system is a design that keeps
changing. Each change means redoing code that has already been written, shifting
plans in midstream, and corrupting the internal consistency of the system.

The problem is that often nobody knows what the program should do until there is
a preliminary version to run. An excellent strategy is to build mock-ups and
prototypes that potential users can start working with early, so that the design
settles down as soon as possible. Once designers hammer out the basic structure of
the system, any changes that aren't critical should wait until the next version. This
is a hard line to hold, but the closer developers can come to it, the better off the
code will be.

Cleanly Divide Up Tasks

When designing a complex system, divide the work into smaller pieces that have
good interfaces and share the appropriate data structures. If you get that right, you
can make many bad implementation decisions without ruining the overall design
and performance of the system.

Object-oriented languages can be a usef ul way to express and enforce the


decomposition strategy, but they don't tell the designer how to do the job. It is
infinitely better to have a good design implemented in C than a poor one in C++.
Avoid Shortcuts

Programmers often don't take time to fix a design error as the code evolves. Those
decisions can come back to haunt everyone. Avoid shortcuts by insisting that each
one is carefully documented. The pain of writing something up can act as a useful
deterrent.

Use Assertions Liberally

An assertion is simply a line of code that says, "I think this is true. If it isn't,
something is wrong, so stop execution and let me know right away." If a value is
supposed to be within a certain range, check first. Make sure that pointers point
somewhere and that internal data structures are consistent.

Just like other debugging code, you can compile assertions out of production code
before it enters final testing stages. There is every reason to lit ter your code with
assertions. You will find problems quickly, making them much easier to track down.

Use Tools Judiciously

Tools are not a panacea -- they can't help you fix a project that is being
administered badly. But tools can make it easier for development teams to put
good policies into effect. Source code management tools, such as the public domain
RCS or PVCS from Intersolv, help you coordinate modules being used by multiple
developers.

There are also some tools that can find certain errors in your code instead of
forcing you to do it. The Unix utility lint (or the turbo-charged version offered in
Centerline's Code Center) will find syntax errors and mismatches between different
source code files. Purify, from Pure Software, and BoundsChecker, from Nu-Mega
Technologies, catch a wide variety of memory errors when they occur, rather than
when they manifest themselves later on. Other tools perform regression tests or do
code-coverage analysis to see if th ere are dusty corners of your program that are
not being exercised.

Rely on Fewer Programmers

An easy way to reduce the number of bugs in a project is to cut down on the
number of people who are involved in it. The advantages are less management
overhead, less need for coordination, and more contact among the team members
who are building the system.

You can reduce the number of people by having individual programmers produce
code more quickly or by reducing the amount of code that needs to be written.
CASE tools, applications builders, and code reuse are all attempts to meet one or
both of these goals. While these products don't always live up to their promise,
they can simplify a project so that a smaller team can handle it.

9 Ways to Write More-Reliable Software

-- Fight for a Stable Design


-- Cleanly Divide Up Tasks

-- Avoid Shortcuts

-- Use Assertions Liberally

-- Use Tools Judiciously

-- Rely on Fewer Programmers

-- Diligently Fight Featuritus

-- Use Formal Methods Where Appropriate

-- Begin Testing Once You Write the First Line of Code

Oliver Sharp is the director of consulting services at Colusa Software


(Berkeley, CA). You can contact him on the Internet at
[email protected] .

You might also like