Integrate early and often
One dig at the voting process goes: "Vote early and often!" The same applies
to integrating software: Doing it early and repeatedly can have a profound
effect on an information technology project's schedule and costs.
Software integration is necessary in many agency projects. For example,
there may be two contractors, one working on communications software and
one working on the middle tier of a three-tier World Wide Web project. The
software products of the two contractors will have to work together for
the system to function properly.
The traditional way to do this is for each contractor to write a detailed
specification or design document. Theory has it that the documents will
nail down all the details, programmers will observe the details and the
software building blocks will just "snap together."
Schedules often are built under this assumption. Unfortunately, it almost
never works out that way.
In a recent project, one vendor wrote a design document that specified
that a file name would go into a specific database field, and the file would
be placed in the C:\transfer directory. Another vendor's software was supposed
to read this field and go get the file.
Integration testing started two weeks late (10 percent of a two-month
programming phase). Indeed, there had been no integration of the products
before testing, so one could argue that the activity was "integration,"
Programmers discovered that their code didn't work. In the data created
by the communications software, there were strange file names and mislabeled
directory paths. For example, C:\ Berkeley\distribution\folder1/x/foo.txt.
The programmers used a default directory name that was inconsistent
with the design document. Hindsight showed the document was ambiguous regarding
"file name": Did it mean a fully qualified file name with the path, or just
the name of the file within the final directory of the path (in this case,
foo.txt)? Also, part of the file name was created by Windows programmers
and part by programmers working on Unix. Unix uses slashes (/) in path names
and Windows uses backslashes (\).
The code was already written, so fixing this problem required changes. Changes
to finished software modules require retesting many functions. And even
if the original programmers are available, they may have forgotten the details
of code written a while ago. In contrast, if the development methodology
had called for frequent integration and limited testing, this error would
have been immediately evident. The programmers would have been there with
the code fresh in their minds. The fix would have taken, perhaps, an hour.
As it was, the fix required three testers working for several hours
at a time over a couple of days. A programmer had moved to another project,
meaning that his part of the code could not be immediately fixed. Managers
already had been feeling pressure, and the total delays were unexpected
and much more substantial than they really needed to be. Bottom line: Integrate
early and often.
Bragg is an independent consultant and systems architect with extensive
experience in the federal market. He welcomes your questions and topic suggestions
at [email protected].