Good, fast and cheap?

There's an old saying that I'm told comes from the printing industry: "You can have it good, fast or cheap — pick any two!" This aphorism has been adopted by the software development industry with enthusiasm because it recognizes the trade-offs between producing high-quality robust software, developing rapidly and keeping costs down.

Of course, we software types prefer the word "inexpensive" to "cheap." After all, nobody wants to write cheap software.

Agency developers and their managers are often squeezed into this corner: The system has to be up and running by Sept. 30. The budget cannot be increased because there is no more money. And of course, all the features in the specifications are essential, and they all have to be implemented in a quality way. Sound familiar?

I'd like to suggest, though, that there are at least two other variables in this equation. One of them I'll call "working smarter." The other is "scope."

You can sometimes escape from the good/fast/cheap box by working smarter. For example, on a recent project, we were required to implement e-mail forwarding and a survey capability for World Wide Web users to record their opinions about various things.

Each of these items could take a fair amount of development. In addition, the e-mail requirement had a fair amount of technical risk. And doing a robust survey solution requires a substantial amount of programming — with a great deal of potential schedule risk if people feel a need to second-guess the user interface, as they sometimes do.

It turned out that we were able to avoid both problem areas by purchasing software off the shelf, saving weeks of developer effort. The e-mail solution came with source code, so we could customize it for about $100. The survey module, also with source code, was about $450. We customized the survey interface with HTML from the team's graphic designer and incorporated the data tables in our existing database, and we were done.

The other variable in the equation, scope, is often adjusted under pressure. Scope means, simply, how much software you have to build, which is another way of saying how many requirements you have to meet. Statistics show that proj- ects often experience a decrease in the number of requirements prior to deployment. Looking more closely, we find that the players in the development project frequently sacrifice functionality in a last-ditch effort to get the software out the door.

If the requirements are managed — and if each requirement is tied to an estimate — they can be consciously traded against schedule or budget constraints in an ongoing dialogue as the project unfolds. For example, do you really need a graphical user interface to manage data that will be loaded into a database once a year and changed seldom or never?

Trade-off decisions made consciously — based on schedule or cost trends identified early in the project — are almost always better than decisions made in desperation at the last minute.

Sometimes it is possible to have it all, if you plan it right.

Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at


Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.