Programming folklore has it that 90% of programmers never
buy a book about programming after they leave school. I'm
not sure I believe that figure, and I've been unable to
verify it or to find the original source, but certainly a
lot of programmers I know would benefit from a wider
acquaintance with the great books of our field. As time goes
on, I want to cover new books that I think are interesting
or important, but I'll also include a lot of the old-timers
that are sitting on my shelves. And, from time to time, I'll
report on books from outside the field that have had an
enormous influence on me. I hope you enjoy this month's
offerings.
Way back in 1980, Meilir Page-Jones wrote a book titled The
Practical Guide To Structured Systems Design (ISBN 0-13-
690769-5). Practical Guide helped popularize the ideas of
structured design. It was clear, concise and easy to read,
and it introduced thousands of programmers to coupling,
cohesion, and all of the rest. I still have a copy of the
2nd edition on my shelf (it was revised and updated in 1988)
and I firmly believe that every serious programmer should as
well.
In WEPSKAOOD, Meilir brings this same clarity of thought to
Object Oriented design. This is not an easy book to breeze
through; it's written for the working programmer/designer
and it's not dumbed down for the dilettante. However, it
should be accessible to anyone who has worked with OO in the
past or who is willing to put some effort into understanding
the future.
The first two chapters (Part 1) form an introduction to OO
and explain the history behind it. Part 2 explains the OO
design notation (OODN) that Meilir uses in the book. This is
the weakest portion and I wish he'd put it in an appendix
instead of burdening the main part of the book with it.
However, it is worth reading at least once, to make sure you
understand the many diagrams he uses throughout the book. If
you're an experienced OO designer, you'll be interested in
the nuances of OODN itself. After all, any language makes
some things easier to express than others, which is why it's
so important to learn more than one language if we want to
be able to describe the richness of the world around us.
Part 3 is the meat of the book, where he explains the
principles of OO design. He explains what good OO design
looks like, why it's good, and when, if ever, it may be OK
to break the rules. He explains how to evaluate a design, to
judge its 'goodness.' He gives us a common vocabulary that
we can use to discuss an OO design.
Instead of overloading (and confusing) the old terms such as coupling and cohesion, Meilir has chosen to use new terms to go with this brave new world. I must confess that I've been feeling rather grumpy about the new terminology. I've muttered to myself every time I've seen somebody use the term 'connascence' on CompuServe, and I haven't even wanted to think abut 'contranascence'! However, after reading the book and thinking about the matter, I now believe that I was wrong. It is important to have distinct terms for distinct ideas and I believe Meilir has chosen well.
"Connascence between two software components A and B means either
1. that you can postulate some change to A that would require B to be
changed (or at least carefully checked) in order to preserve overall
correctness, or
2. that you can postulate some change that would require both A and B to be
changed together in order to preserve overall correctness."
This book is an excellent summary of the practical lessons
that we have learned using OO in the last few years. I think
it's going to be an important book, one that every serious
programmer should read and think about.
Larry Constantine is one of the names in the programming
profession. He was making major contributions to the field
as far back as the 60's, with his pioneering work on
Structured Design, and he's still contributing today. He did
take 10 years out (in the late 70's and early 80's he worked
as a family therapist) but he's back now and we're richer
because of it.
This book consists of 37 short essays, most of which were
first printed in Larry's column in Computer Language
Magazine and Software Development Magazine. The topics range
over a large number of subjects, from Group Development to
Cowboy (and Cowgirl) Coders, Work Organization, Tools and
Methods, Process Improvements, and Usability issues. Larry
seems to have used his 10 year vacation well, On Peopleware
is full of insights about people, about how to work with
them, and how to build programs that will make their work
(and play) less stressful and more effective.
This is a fun book to read--Larry's not shy about pointing
out when the emperor has no clothes! His analysis of popular
GUI conventions left me squirming several times, as I
thought about some of the systems I have designed. My
biggest complaint is that I wanted more information on what
makes an interface bad (or good). I feel like I can critique
an existing system pretty well, but I'm not sure that I know
how to create one that is a whole lot better. Of course,
it's probably impossible to reach that level of detail in a
monthly column, so if Larry ever writes a textbook on
interface design he has at least one buyer! In the meantime,
buy this book. The chapters are just long enough to make
great lunch time reading. You'll feed your mind at the same
time you feed your tummy.
Bruce Tognazzini is a well known authority on user
interfaces. He was heavily involved with the design of the
original Macintosh interface. He recently spent 3 years
working on a secret project for Sun Microsystems, exploring
the possibilities and challenges that will face computer
users 10 years from now. This book (and the accompanying 13
minute video that you can order from Sun at cost) is the
result of that project, which was known as 'Starfire'. It
describes the Starfire vision and explores some of the
challenges we face if we are to get there from here.
I've noticed that Macintosh computers appeal to different
people than PCs do. The interfaces and accepted conventions
of the two systems are very different and it's rare for me
to find a person who is equally comfortable in both worlds.
I'm definitely a PC person and I have my share of
disagreements with Tognazzini's vision. But it's not
necessary to agree with everything he says in order to get
value out of this book. He's raising issues that we will
have to deal with, sooner or later, and we'd better deal
with some of these (such as how to preserve our security and
privacy in a connected world) sooner! Before we lose the
liberties we take for granted!
In Tognazzini's view of the future, computers are
ubiquitous. They're such a part of our lives that we rarely
notice them, any more than we notice the air that we
breathe. Everything is connected, everything is
standardized, your 'office' is just as apt to be a rented
portal in an airport as it is the cubical in corporate
headquarters with your name on it (assuming that such a
private, dedicated space even exists by then.) And, it
doesn't make a difference! You'll have the same full use of
your files and knowledge base while you're sitting in a seat
30,000 feet in the air as you would if you were safely at
work or at home. (No more LapLink!)
I believe that the future Tognazzini envisions is possible,
but I don't think it will be easy and I don't think that the
hardest problems will be technical. His vision will require
an enormous amount of cooperation and standardization
between systems, people, and corporations that have
historically been rivals. It will require us to create
workable standards and to agree on them very quickly, lest
the world become a mish-mash of incompatible Babels. It's a
nice dream; but human nature being what it is, I don't think
it's very likely. I'm not even convinced that it's 100%
desirable. In Tognazzini's world, software designers create
user interface standards, using the best scientific and
psychological studies of the day, and the rest of us live
with them. I may be tilting at windmills here, but I'm not
comfortable with some designer, sitting in a cubical
somewhere, deciding what will make my day more productive. I
don't care what the latest tests show about how a mouse is
faster than a keyboard. If I want a keyboard, I want a
keyboard! And making me unhappy isn't going to make me more
productive!
Still, all gripes aside, I did enjoy this book. Tognazzini
is an amusing writer and he brings several unusual
viewpoints to the table. I've seen Zen mentioned before in
books about computing, but this is the first time I've ever
seen magicians and performance artists discussed. And it
seems that the good ones have a surprising amount in common
with the good interface designers! This book taught me some
things about indirection and illusion that I'll be able to
use in my current project, and I'm sure that my users will
be happier because of it.
Let's face it, I'm a techie. I like computers. They don't
get tired, grumpy, or illogical. They do what I tell them to
do (usually, anyway), and they don't complain in the
process. However I'm still human, which means that I do have
to deal with other people at least part of the time. Since
many of those people are my family, my friends, my coworkers
and customers, the more skilled I become at human
interactions the easier my life will be.
If you're like me, a large part of your daily interactions
with other people will involve both giving and getting
feedback. Luckily, effective feedback skills can be learned.
I know, because my friend Jerry Weinberg has taught me a lot
about feedback in the past couple of years. And most of what
I've learned (and am still learning today) is in this book.
It's well-written, with great examples, memorable rules of
thumb, and a lot of creative ways to practice your new
skills. Who knows, it may even make your computer like you
better! (After all, we give ourselves feedback, as well. And
I know my work improved when I learned to recognize the
signs of ineffective feedback, and some ways to give myself
feedback more effectively.)
Copyright © by Sue Petersen. All Rights Reserved.