A few years ago, somebody wrote an angry letter to the
editor of Stereo Review Magazine. This reader was irritated
because it seemed to him that the reviewers almost always
found good things to say about the classical music they
reviewed but often seemed very critical of the popular and
rock selections that they chose to cover. He felt that his
musical tastes were being discriminated against.
Stereo Review's editor wrote back and explained that it
probably was true that there was a higher percentage of
favorable reviews in the classical section of his magazine,
however, this did NOT mean that Stereo Review was attempting
to discriminate. Classical music has been around for a long
time, and the canon has been well filtered over the
centuries. The shallow, the trivial, and the junk didn't
survive the winnowing, only the best of the best is left.
Thus, it was very natural that the reviewers would be able
to find a higher percentage of classical works and
performances that were worthy of praise.
The programming profession certainly doesn't have centuries
of history behind it, but still, people have been thinking
about and writing about programming for several decades. It
should be possible to pick out books, people, and ideas that
have stood the test of time and that have proved themselves
worthy to form a core body of knowledge for the field. I'm
sure I haven't discovered all of these gems, but I do
believe I've got a fair percentage of them on my shelves.
I'll try to include some of my favorites in each column, as
well as whatever new selections cross my desk that strike me
as interesting or potential additions.
"Reduce your discipline --whatever it is--to a logical
sequence of clearly thought sentences. You will thereby make
it clear not only to other people but to yourself. You will
find out whether you know your subject as well as you
thought you did. If you don't, writing will show you where
the holes are in your knowledge or your reasoning."
quoted from page 198
Jerry Weinberg once told me that he'd discovered a quick and
useful way to learn any subject that interested him. First
he studies it enough to be able to teach a course on it.
Then, when he thinks he knows enough, he writes a book about
it. The process of writing that book solidifies the
knowledge in his blood and bone, it points out where he has
a solid understanding and where the weak spots are in his
chain of logic. I've used this method myself, and I can
confirm that it works. I've known and used the techniques of
data normalization for several years. But, when I recently
spent a month writing an article about normalization, the
Normal Forms became a part of me like never before.
Zinsser writes clearly and enthusiastically about the craft
of nonfiction writing. He appreciates it when others do the
same. He rarely lectures in this book, he SHOWS us how to
write well. He has found superb examples of good writing
from disciplines as diverse as jazz, geology, and high
energy physics. I will never again feel insecure and just
plain dumb when I find a piece of text that is obscure or
incomprehensible, Zinsser has shown me that it IS possible
to write a clear explanation of any subject. And, even
better, he has shown me HOW.
Writing To Learn isn't a How-To book, although Zinsser has
written one of those as well (On Writing Well, Harper
Perennial, 1990). Rather, this is a Why-To book. He
convinced me, give him a chance, I think he'll convince you
as well!
Programming On Purpose -- Essays on Software People
by P.J. Plauger
PTR Prentice Hall, Inc., 1993
ISBN 0-13-328105-1
204 pages, (paperback)
Programming On Purpose -- Essays on Software Technology
by P.J. Plauger
PTR Prentice Hall, Inc., 1994
ISBN 0-13-328113-2
224 pages, $28 (paperback)
P.J. Plauger has been teaching us and enlightening us for
many years. He comes closer than anybody else I know to
being a true philosopher of Software Engineering. For many
years he wrote a monthly column for the old Computer
Language magazine. And, except for the last few columns,
every single one of those essays can be found in these
books, from columns dated July 1986 through Dec. 1992.
The first collection, Software Design, probably comes
closest of the three to being a 'normal' computer book. Here
you will find the discussions of coupling and cohesion,
'Writing Predicates', 'Generating Data', how to recognize
the right tool at the right time, and how to break the rules
when it's really, really necessary. (And how to recognize
when it's REALLY necessary!) At first glance, much of this
book might appear to be rather dated in today's OOPY, GUI
world. That impression is wrong. DEAD wrong. I don't care
how OOPY-GUI your code is, you still have to worry about
flow of control. You still have to get those pesky
predicates right, and you still want to write cohesive
methods, with low coupling. You still need to encapsulate
your data, to lock it up so that the neighborhood bullies
can't get to it. Plauger has decades of experience backing
up what he says here, he's written and influenced the
creation of more software than most of us have ever dreamed
of. He's seen all the errors and the great ideas that didn't
work out in practice. He's hit all the brick walls out
there. He's willing to give you a road map, I suggest you
use it! (Note - be sure to bring a couple of extra
highlighters along on your journey, you'll use them!)
The second collection, Software People, includes the essays
that concern people stuff in some way, shape or form. Here
he covers many diverse subjects, from ethics to copyright
law, from politics to 'Customer Service' and what it takes
to run a SUCCESSFUL business. I've spent the last couple of
afternoons sitting on the deck, browsing this book. I'm
using my highlighter a LOT! Here's a short section on time
management that will probably end up on my refrigerator.
"The basic message of this Great Truth is that you
don't have to overhaul yourself completely to be more
effective at getting things done. You just have to learn
where to expend that minimum extra effort to up your
efficiency in the areas that really count. The rest of
the time you can continue to be the good-natured slob
you've always been."
quoted from page 45, 'Awaiting Reply'
Wow!
And, as the frosting on the cake, this book contains what is
probably my favorite Plauger essay of them all, where he
names and defines the difference between the 'Reluctant
Programmer', the 'Determined Programmer', and the
'Enthusiastic Programmer'. (page 93, 'The Physicist as
Programmer'). At last I understand why some people look at
me funny when I go off in a daze, debugging some section of
code, instead of eating dinner or doing the dishes.
The third collection, Software Technology, is harder to
classify, it's a bit of a grab bag of whatever didn't fit
into the first two volumes. It includes all of the April
Fools columns (some of which are a bit too close to reality
for comfort!) It includes the technological columns,
hardware, software, and bioware. The discussions of the
physiology of sight, hearing, and touch are much more
concise and to the point than you'll find in most medical or
biological textbooks. If you're wondering what the future
holds for us in realistic and truly awesome interfaces, or
even better, if you're involved in creating that future, you
need these essays. The book includes discussions of computer
arithmetic and public key cryptography. Of 'Economizing
Polynomials' and 'Approximating Functions', along with a
dynamite essay on 'Technical Writing' and... By what go on?
By now you should have gotten the point. BUY THESE BOOKS!
You will not regret it.
This is one of the most unusual books I've seen this year,
in fact I'm not sure it's a 'book' at all. It strikes me
more as an index, a reference list, to some of the best
engineering practices of the last 30 years. Davis says 'If Software Engineering is really an engineering discipline, it is the intelligent application of proven principles, techniques, languages, and tools to the cost-effective creation and maintenance of software that satisfies users' needs.' And here, Davis has collected 201 candidates for
Software Engineering Principles, along with references that
point you to the original sources. We've all read books with
yellow highlighters in our hands. 201 Principles is a
collection of the yellow highlights from all those books and
periodicals you've been meaning to read just as soon as you
had a free afternoon.
None of these ideas are new, none of them are particularly
original or shocking, but... your project WILL be better off
if you understand these principles, if you know when you're
keeping them and know when (and why) you're breaking them.
Davis sorts the principles into 8 general categories:
General, Requirements Engineering, Design, Coding, Testing,
Management, Product Assurance (configuration management,
quality assurance, verification and validation), and Evolution
(entropy will get you in the end!). Each principle gets a
number, a catchy title, a short one or two paragraph
discussion, and a footnote at the bottom of the page with
the reference where Davis found the principle.
201 Principles is an interesting and important book, that
just misses greatness. I loved the titles of each principle.
They are short and catchy, easy to understand, hard to
forget. Who can misunderstand Principle 113 'A Successful
Test Finds an Error', or Principle 188 'Fix Problems, Not
Solutions'? I think the book is more than worth it's
relatively modest price just for the references on the
bottom of each page. But the discussion of many of the
principles is abstract and unsatisfying. The writing is dry
and academic, it left me longing for more humanity and meat.
(It's hard to believe that the same person wrote the titles
and the commentary!) Of course, there is no way you can
expect to learn a principle from a summary book such as this
one, but I'm afraid that a manager somewhere might pick this
up, look at it, and then put it down again because the
writing is too dense to be worth bothering with. And that
would be a pity, we need to understand these principles,
they are much more than just pie-in-the-sky theory.
Copyright © by Sue Petersen. All Rights Reserved.