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," not "testing."

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 tbragg@acm.org.

Featured

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.