have it all, and it's just a matter of finding the ideal tools and processes to accomplish development miracles.
How do you handle these problems when you sit down
to design
a client/server application? If you can't offer end users miracles, give them a pragmatic alternative: good-enough software. Now the mantra of Silicon Valley software developers, this concept strikes a practical and realistic compromise among the elements that go into our traditional definition of software quality: zero defects, on-time schedules, in-budget costs, and end-user-requested feature
s.
Here are some reasons why your next client/server application might be better off if it's just good enough.
Software Quality
We need to readjust our view of software quality. Our traditional definition has become elusive in the client/server world, especially now that client/server includes entities like intranets and Java. Software developers have typically used the word
quality
to describe a bug-free system that meets the user's requirements and is delivered on time and within budget. In reality, it's a word that describes few actual systems. As we'll see, the very definition of quality is the decisive factor in designing client/server systems successfully.
The three main ingredients for delivering this form of quality are people, technology, and processes. The people ingredient is crucial -- and obvious. An organization with mediocre programmers is not going to create high-quality systems, no matter what language they write their code in.
The second in
gredient -- technology -- is where most software developers concentrate their efforts. That's no big surprise, considering it's where client/server systems achieved their first great triumph over mainframe systems. The technology of intelligent workstations and GUIs provides end users with higher-quality systems than dumb-terminal, character-based mainframes. The technology of visual, RAD-oriented (rapid application development) environments -- Visual Basic, Delphi, PowerBuilder, and others -- helps us build systems faster than we could in the COBOL and mainframe days.
Alongside these technological improvements, we also encountered some new problems. For instance, client/server technology typically involves open systems, which means that developers face a heterogeneous mix of hardware platforms, OSes, middleware, DBMS packages, languages, and protocols. It's all supposed to work together, but it's usually more complicated than in the days of closed, proprietary environments. And when something goes wron
g, every open-systems vendor points a finger at someone else.
While the technology problems may be more subtle, they are similar to the problems with structured methodologies in the last generation. Here's the paradox: If the technology really does work, it lets us achieve the disaster sooner than before.
Thus, the technology of GUIs is ultimately useless if we don't know what "business data" to display. Also, the rapid-programming technology of Visual Basic does not eliminate the need to figure out what "business problem" the end user is trying to solve.
But wait. Isn't that what rapid prototyping is supposed to do for us? As every modern developer knows, one reason that languages like Visual Basic have been so successful is that you can develop GUIs and applications prototypes rapidly -- and then iterate equally rapidly until they meet the user's needs. Used well, this can be enormously successful. Used poorly, it's like throwing mud against a wall and hoping that some will stick. The fact
that a visual programming language lets us throw mud against the wall more quickly doesn't necessarily mean that any more of it is going to stick.
It's the Process, Stupid
In any case, what's really going on here is the use of technology to support a process. Such processes have names like prototyping, spiral development, or RAD. As our client/server projects have begun to scale up in size and complexity, we've learned that it helps to pay closer attention to the details of the process before we simply let our admittedly good technology start throwing mud against the wall. A good example of a client/server development process is the one recommended by consultant Lou Russell (see the figure
"Quality Design"
).
The initial activities of business reengineering, defining business events, and documenting the analysis requirements will likely determine the real success of the client/server project. Given the pressures found in today's business environments, you h
ave to carry out these activities relatively quickly -- but you
do
have to carry them out. No one can afford to spend five years drawing data-flow and entity-relationship diagrams the way we did in the 1970s. You probably won't even have five months. But it might well be worth spending five weeks, and, unless it's a trivial project, it's usually worth spending at least five days on these initial activities.
However, we can't perform this analysis activity only once, as we did with our old waterfall life-cycle processes. We must be prepared to carry out the analysis activity (along with all the other activities in the client/server development figure) repeatedly, for each deliverable "version" of the system.
Unfortunately, the structured analysis/design methodologies from the 1970s were often associated with sequential, waterfall development processes -- and thus many developers rejected them as they embraced the iterative processes associated with client/server projects. Even without this
problem, however, there has been a steady movement toward object-oriented (OO) methodologies. Object technology is usually more appropriate for building the GUIs that dominate many of today's client/server systems. Furthermore, object technology is usually a better foundation for reuse (which is another important technology for improving productivity and quality).
This last remark deserves emphasis: Technology can support, and ultimately automate, many processes. Thus, we should look for technology to support the early activities of business reengineering and analysis. Among the excellent products in this area are Popkin's System Architect, Platinum Technology's Paradigm Plus, Interactive Development Environments' Software Through Pictures, and Cadre/Cayenne's TeamWork products. They support both structured and OO methodologies. If you have made a wholesale commitment to object technology, you should also take a look at Rational Software's Rose, Mark V Systems' ObjectMaker, and Object International's T
ogether/C++.
Regardless of which OO tool you use, one important early stage of analysis is the identification of
use cases
, roughly equivalent to the
business events
associated with structured analysis. Ivar Jacobson introduced use case in his first OO book (
Object-Oriented Software Engineering
). Several methodologists recommend use case for documenting the essential details of how the business user intends to interact with the system.
Several recent OO books (e.g., Jacobson's
The Object Advantage
and
Mainstream Objects
by Yourdon, Whitehead, Thomann, Oppel, and Nevermann) illustrate the use-case approach, and most of the popular OO analysis/design tools support the diagramming notation (see the figure
"A Typical OO Use-Case Diagram"
).
Wouldn't it be nice if this were all we needed? A solid OO method, with particular emphasis on use cases; some good analysis/design CASE tools, followed by a powerful visual programming language
; and plenty of prototyping to deliver incremental results to the impatient customer.
Obviously, this is not the case. With all the above procedures, why is it that client/server projects are developing the same reputation for schedule delays, budget overruns, and unfulfilled functionality that remind us so unfondly of the old mainframe days?
Is it because the implementation details -- especially the integration of heterogeneous hardware/software components -- are so difficult? Is it because most client/server project teams are skipping the early stages of analysis and design, and plunging headlong into coding, thus providing brilliant solutions to the wrong problem?
Or could it be because we need to shift our attention back to the people and management issues, as is suggested in some recent textbooks by Grady Booch (
Object Solutions: Managing the Object-Oriented Project
) and Adele Goldberg and Kenneth S. Rubin (
Succeeding With Objects: Decision Frameworks for Project Managemen
t
)?
When Good Enough Is Good Enough
All the above probably play some role. However, the larger answer may be that our expectations for bug-free software developed on time, within budget, and with every feature that end users have asked for is unrealistic. By definition, these goals impose four interrelated constraints on developers, and by attempting perfection in one area, developers will likely create havoc in at least one other area. Indeed, because relationships between defects, time, cost, and features are nonlinear and nearly inverse, it's almost impossible for development teams to intuitively predict, say, the impact of a scheduling crunch on cost, defects, and features.
That's why just producing an up-front specification for good-enough software isn't enough. You and your end users must engage in a
dynamic
reevaluation of the specification, because most development projects take place in what author James Bach justly calls a "mad world." On a daily basis, t
he project team may find that the hardware has changed, the tool vendors have changed (some bankrupt, others brand new), government regulations have changed, the economy has changed, and the business risks have changed. Consequently, the user's requirements for the system change, and the design and implementation must change, too.
Of course, prototyping is entirely compatible with mad-world, good-enough software development. However, many development teams -- with the best of intentions -- start their projects with fixed front-end analysis/design processes, and with a built-in conviction (based on decades of tribal folklore) that all bugs are evil and that all requirements are doable, even within ridiculous schedule and budget constraints. The reality is that some bugs are better than others (as suggested by the familiar term
showstopper
), and that our systems will go into production with known bugs that the project team has not been able to eliminate -- as well as latent bugs that the project
team isn't even aware of.
A realistic objective for nontrivial client/server projects in today's pressured business environment is that we will consciously choose which bugs will be in the product we ship. The consequences of this cold-blooded, good-enough approach are primarily evident in the latter stages of coding and testing, but they have strong implications in the earlier stages of a project, too.
Even more important in the early stages of a project is the concept of
triage
. Twenty years of cost and schedule overruns should tell us that our customers will ask for more than is reasonable and that we will not deliver it all. Rather than waiting until the day before the deadline to decide which parts of the system work and which don't, you should address this issue from the very beginning of the project.
The questions to ask the customer are these:
-- Which requirements are essential
(i.e., without them, the system can't be used at all)?
-- Whic
h requirements are important
(i.e., without them, the system will be difficult or unpleasant to use)?
-- Which requirements are optional
(i.e., the "bells and whistles" that would make the system fun and interesting to use, but which aren't essential or even important)?
If the customer categorically decrees that all requirements are essential, you're doomed. It's likely that the project team will be late and over budget, even with good people, good tools, and good processes. If you can accomplish a rational triage, however, there's a good chance you'll finish the must-have features and perhaps even some of the should-have features. The could-have features may not even make it into the design phase of the project.
In today's mad world, we also have to reevaluate this triage on a daily basis. Yesterday's must-have requirement could become irrelevant if our user's strongest competitor suddenly goes bankrupt. Also, entirely new requirements can emerge at any point dur
ing the lifetime of the project. All this means that we have to focus more and more attention on
requirements management
, an activity that comes before the detailed analysis and design modeling handled by the tools described earlier.
The tools used for this activity are word processors, because users typically describe their requirements in imperative English sentences like "the system
must
do X, Y, and Z." Associated tools such as RTM (from Marconi Systems), Doors (from Zycad), and Requisite Pro (from Requisite) can help describe the priority, cost, risk, and other attributes of each requirement.
As the attributes change dynamically throughout the project, requirements management tools can help ensure that the team remains focused on the must-have features, without being distracted by the could-have features that should be sacrificed to deliver something that is good enough.
Acceptable Compromises
Good-enough software is a controversial concept. In fact,
many traditional software engineers reject it as an apology for mediocrity. But realistically, all forms of engineering involve making explicit, rational compromises in a world of finite resources. The trick is to ensure that both the developer and the customer understand what those compromises are, and that they both agree that the result of these compromises are indeed good enough.
Visual programming languages may help us write more code more quickly than ever before. OO analysis/design methods and tools may help us understand the details of the user's requirements more clearly than before. However, if we are to achieve success in the complex world of client/server systems, we'll have to learn to apply triage to the requirements at the beginning -- and throughout the life -- of the project.
Bibliography
Bach, James.
"The Challenge of Good Enough Software."
American Programmer, October 1995.
Booch, Grady.
Obje
ct Solutions: Managing the Object-Oriented Project.
Addison-Wesley, 1996.
Goldberg, Adele and Kenneth S. Rubin.
Succeeding with Objects: Decision Frameworks for Project Management.
Addison-Wesley, 1995.
Jacobson, Ivar.
Object-Oriented Software Engineering.
Addison-Wesley, 1992.
Jacobson, Ivar.
The Object Advantage: Business Process Reengineering with Object Technology.
Addison-Wesley, 1994.
Russell, Lou.
"Teaching Old Dogs New Tricks."
American Programmer, November 1995.
Yourdon, Edward, Katharine Whitehead, James Thomann, Karin Oppel, and Peter Nevermann.
Mainstream Objects.
Prentice-Hall, 1995.
Where to Find
Cadre/Cayenne Software
Burlington, MA
Phone: (617) 273-9003
Fax: (617) 229-9904
Interactive Development Environments
San Francisco, CA
Phone: (415) 543-1314
Fax: (415) 543-0145
Marconi Systems
Reston, VA
Phone: (703) 736-3500
Fax: (703) 736-3556
Mark V Systems, Ltd.
Encino, CA
Phone: (818) 995-7671
Fax: (818) 995-4267
Object International, Inc.
Raleigh, NC
Phone: (919) 772-7734
Fax: (919) 772-9389
Platinum Technology, Protosoft Division
Houston, TX
Phone: (713) 480-3233
Fax: (713) 480-6606
Popkin Software and Systems, Inc.
New York, NY
Phone: (212) 571-3434
Fax: (212) 571-3436
Ptech
Cambridge, MA
Phone: (617) 577-7100
Fax: (617) 577-7400
Rational Software Corp.
Santa Clara, CA
Phone: (408) 496-3600
Fax: (408) 496-3636
Requisite, Inc.
Boulder, CO
Phone: (303) 499-9177
Fax: (303) 499-9535
Zycad Corp.
Reston, VA
Phone: (703) 904-4360
Fax: (703) 834-6622
HotBYTEs
- information
on products covered or advertised in BYTE
illustration_link (15 Kbytes)
Budget, schedule, functions, and defects all affect the design -- mandating on ongoing design process.
illustration_link (18 Kbytes)
Expect business practices and tech
nologies (which may both be changing) to affect the ongoing design process.
illustration_link (13 Kbytes)
A use-case diagram portrays roles (e.g., clerk) and activities (e.g., loan application) and the connections between them.
Edward Yourdon, developer of the "Yourdon method" of structured systems analysis and design, and codeveloper of the Yourdon/Whitehead method of OO analysis and design, and the Coad/Yourdon OO methodology, is the author of over 200 technical articles and 22 computer books, including, most recently, The Rise and Resurrection of the American Programmer and The Decline
and Fall of the American Programmer. You can contact him at
http://www.yourdon.com
.
When Good Enough Is Best
