Playing good defense

As the NCAA college basketball tournament winds its way to the final, it

may be useful to think about playing defense in a different arena: agency

software development. Over the years, I've seen a number of projects take

unexpected turns. In software, anything unexpected is seldom good news.

What can agency managers do to protect themselves?

Perhaps one of the first defensive maneuvers involves milestones. Peter

Coad, the object-oriented guru and founder and president of Object International

Inc., has a mantra that applies here: Frequent visible results.

On software projects, even large ones, you want to be able to see some

visible result at least every two weeks. This means technical meetings,

prototypes, document outlines and white papers during analysis and design.

And it means prototype refinements and seeing running code during implementation.

You can arrange for these visible results during the project planning stage.

Simply identify and track them with planning software such as Microsoft

Corp.'s Project or Time Line Solutions Corp.'s Time Line.

What kinds of results should you look for? One of the best approaches

is to identify the hard parts of the project ahead of time and ask for results

that illuminate these risky areas. If database performance is an issue,

an early benchmark may be just the ticket. Or if integration with a commercial

off-the-shelf package is a risk (and it usually is), ask to see a transaction

that travels from the custom code to the COTS package and back.

Mini-demos for agency software development managers or functional user representatives

are a great way to mark these milestones. Successful demos build confidence

in projects and let users know that something is being done about their

problem. Unsuccessful demos highlight problems needing attention — and in

software development, the earlier the attention, the less costly the fix.

Another defensive move is having frequent "code drops" and code integration.

A code drop is a delivery of code by a programmer into a common repository.

Using a configuration management/source code control system, such as Merant

International Ltd.'s PVCS, Microsoft's SourceSafe or MKS Inc.'s Source Integrity,

is a good way to manage a repository.

It makes sense to have the repository located on a computer in the agency's

offices. If developers are working in a contractor facility, this provides

an automatic remote-site backup. It's also a great place for an independent

build of a demo executable.

I would argue, in fact, that not insisting on frequent source code check-ins

or code drops can rise to the level of software development management malpractice.

How can you allow developers to develop for months, or in some cases years,

and never see the code? How do you know that what's being done is being

done well if you never look behind the curtain of an orchestrated demo?

Playing good defense is as important in agency software development

as it is in the NCAA basketball tournament — and, most would argue, the

stakes can be a great deal higher.

Bragg is an independent consultant and systems architect with extensive

experience in the federal market. He welcomes your questions and topic

suggestions at tbragg@fcw.com.