Object-Oriented
Design with Applications
2
nd
edition
(??) by Grady Booch,
Benjamin/Cummings, 1993 (??).The Booch method is one of the original, most
basic, and most widely referenced. Because it was developed early, it was meant
to be applied to a variety of programming problems. It focuses on the unique
features of OOP: classes, methods, and inheritance. This is still considered
one of the best introductory books.
Jacobsen
Object
Analysis and Design: Description of Methods
,
edited by Andrew T.F. Hutt
of the Object Management Group (OMG), John Wiley & Sons, 1994. A summary of
Object-Oriented Analysis and Design techniques; very nice as an overview or if
you want to synthesize your own method by choosing elements of others.
Before
you choose any method, it’s helpful to gain perspective from those who
are not trying to sell one. It’s easy to adopt a method without really
understanding what you want out of it or what it will do for you. Others are
using it, which seems a compelling reason. However, humans have a strange
little psychological quirk: If they want to believe something will solve their
problems, they’ll try it. (This is experimentation, which is good.) But
if it doesn’t solve their problems, they may redouble their efforts and
begin to announce loudly what a great thing they’ve discovered. (This is
denial, which is not good.) The assumption here may be that if you can get
other people in the same boat, you won’t be lonely, even if it’s
going nowhere.
This
is not to suggest that all methodologies go nowhere, but that you should be
armed to the teeth with mental tools that help you stay in experimentation mode
(“It’s not working; let’s try something else”) and out
of denial mode (“No, that’s not really a problem.
Everything’s wonderful, we don’t need to change”). I think
the following books, read
before
you choose a method, will provide you with these tools.
Software
Creativity
,
by Robert Glass
(Prentice-Hall, 1995). This is the best book I’ve seen that discusses
perspective
on the whole methodology issue. It’s a collection of short essays and
papers that Glass has written and sometimes acquired (P.J. Plauger
is one contributor), reflecting his many years of thinking and study on the
subject. They’re entertaining and only long enough to say what’s
necessary; he doesn’t ramble and lose your interest. He’s not just
blowing smoke, either; there are hundreds of references to other papers and
studies. All programmers and managers should read this book before wading into
the methodology mire.
Object
Lessons
by Tom Love
(SIGS Books, 1993). Another good “perspective” book.
Peopleware,
by Tom Demarco
and Timothy Lister
(Dorset House, 1987). Although they have backgrounds in software development,
this book is about projects and teams in general. But the focus is on the
people
and their needs rather than the technology and its needs. They talk about
creating an environment where people will be happy and productive, rather than
deciding what rules those people should follow to be adequate components of a
machine. This latter attitude, I think, is the biggest contributor to
programmers smiling and nodding when XYZ method is adopted and then quietly
doing whatever they’ve always done.
Complexity,
by M. Mitchell Waldrop
(Simon & Schuster, 1992). This chronicles the coming together of a group of
scientists from different disciplines in Santa Fe, New Mexico, to discuss real
problems that the individual disciplines couldn’t solve (the stock market
in economics, the initial formation of life in biology, why people do what they
do in sociology, etc.). By crossing physics, economics, chemistry, math,
computer science, sociology, and others, a multidisciplinary approach to these
problems is developing. But more importantly, a different way of
thinking
about these ultra-complex problems is emerging: Away from mathematical
determinism and the illusion that you can write an equation that predicts all
behavior and toward first
observing
and
looking for a pattern and trying to emulate that pattern by any means possible.
(The book chronicles, for example, the emergence of genetic algorithms.) This
kind of thinking, I believe, is useful as we observe ways to manage more and
more complex software projects.