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
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