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 [email protected]