by Evan Robinson
Did I say life changes? From contracting I've moved back into a regular spot in a company, herding cats. We managed to survive hurricane force winds (although the water did get at least 10 feet inside the closed kitchen door, with weather-stripping AND a quilt hung over it) and a good-sized eucalyptus tree down on the road. Maybe I should consider telecommuting from somewhere warmer...
Anyway, this quarter I've got a trio of nice entertaining volumes for you: one light and airy, easy to pick up, read for a minute or two, and put down; one heavy and dense, requiring a substantial investment of time and thought to absorb completely; and a classic re-issued. They're of a type, however, in that they all attempt to pass on hard-won experience from one set of people to another.
A side note on the prices I put in the headers. They are the price I find on the book at my local store, which may or may not be suggested retail. If I progress to the point of getting material directly from publishers I may begin putting the suggested price in instead. If I do, I'll let you know.
Another life change, by the way - I've moved again. Fortunately email addresses follow you wherever you go (because there you are). Feel free to email me.
201 Principles of Software Development
Alan M. Davis
McGraw-Hill, 240 pages, $24.95
This is one of those books I just love to find. It is instructive and useful, and you can pick it up for 3 minutes and get something wonderful out of it. With the exceptions of the Preface and Introduction, no standalone element of this book is longer than a single page. I'm almost tempted to put my copy in the bathroom at work...
201 Principles is broken into sections of General Principles, Requirements Engineering Principles, Design Principles, Coding Principles, Testing Principles, Management Principles, Product Assurance Principles, and Evolution Principles. Each section contains 10 to 50 principles of development. As explained in the Preface, a "principle is a basic truth, rule, or assumption...that holds regardless of the technique, tool, or language selected." These principles selected are not original with Mr. Davis, but come from a variety of sources. Each principle includes a reference to another work with additional material on the principle.
OK, so what constitutes a principle of software development? How about #10, "Plan To Throw One Away"? - well-known advice from Fred Brooks in The Mythical Man Month (but see the 3rd review this month). One I think our industry could take to heart is #148, "Avoid The Impossible", which is further described as:
"This may seem like obvious advice. On the other hand, many projects commit to delivering their product on schedules that are 100 percent impossible. Barry Boehm has defined the "impossible region" as a relationship between the expected time to develop a product and the number of person-months to be consumed. Specifically, the elapsed time from writing a software requirements specification to product delivery will not be less than 2.15 times the cube root of person-months, that is,
T >= 2.15 * (PM)^(1/3)
Ninety-nine percent of all completed projects have obeyed this rule. What makes you think you can do better? If you still think you can, see Principles 3, 19, 158, and 159."
The contents of Principles 3, 19, 158, and 159 are left as an exercise for the reader :-). I recommend this book highly. It, like Code Complete (which it references several times), is an attempt to pass along fundamental experience to the next generation of software engineers. Because of its tight writing and memorable principle headlines, as well as a treasure trove of references, I think it'll succeed admirably at that task.
Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Addison-Wesley Professional Computing Series, 395 pages, $41.75
Here's a volume that just screams "TEXTBOOK" at me. I almost left it on the shelf because of that mental mapping that said Junior High School Math Book. Just something about the Addison-Wesley label, I guess.
It would have been a shame if I had done that. This may be one of the most useful books on "Object Oriented" anything that I've ever read. Object Orientation (OO), whether it's Object Oriented Programming (OOP), Object Oriented Programming Languages (OOPL), Object Oriented Design (OOD), or Object Oriented Analysis and Design (OOAD), is everywhere these days, and just because something is labeled "Object Oriented" doesn't make it so. And it doesn't make it useful, and it doesn't make it easy, and it doesn't make it reusable. But the best of the material on Object Oriented systems is, in my opinion, something that over time will make us write code which is easier for other programmers to use, easier for us to reuse, and easier to put together into systems that work right. This book can help you do that.
The fundamental concept of a Design Pattern is that there are similar systems that can be used over and over again, in different situations, with different implementations. Pulleys and levers, for instance, are used in sail rigging, teeter-totters, trains, and cars. The fundamental nature of a pulley or lever doesn't change in these various applications, but the specific implementations differ wildly. This book applies the concept to software.
Rather than just supplying code for a series of classes which perform certain tasks (although there is an example implementation of each pattern), Design Patterns provides descriptions (using class diagrams and text) of sets of classes which collaborate as a system to solve a group of problems.
An example near and dear to our hearts is the problem of writing a single set of code which will run under multiple target systems. The specific example provided is windowing systems (Presentation Manager, X, Microsoft Windows, etc.), but it could easily be altered to be multiple systems implemented in different hardware (3DO M2, Sega Saturn, Sony PSX, Microsoft Windows 95, etc.). The authors refer to the pattern as Bridge, and the intent of the pattern is to "Decouple an abstraction from its implementation so that the two can vary independently." The technique allows for run-time (most of us would be happy with compile-time) selection of the target system without requiring client code to know specifics about the target systems. The client code is, however, limited to a common set of operations (an abstraction) across the various target implementations.
Odds are you know some of the patterns (or at least an expression of them) listed here. But with 23 patterns, each with code, diagrams, and textual descriptions, it's likely there's something new here for you.
The Mythical Man-Month (20th Anniversary Edition)
Frederick P. Brooks, Jr.
Addison-Wesley, 322 pages.
It's often wonderful when a friend from your youth comes back to you, whether that friend is a person, a place, or a book. That's how I feel about the 20th anniversary edition of Fred Brooks' classic The Mythical Man-Month. Any of you who have a computer science degree have heard of this book, and most of you should have read it.
But in case you haven't, here's your chance. Addison-Wesley has provided us with a new version of TMM-M with four new chapters: a condensation of the propositions asserted in the original; Brooks' view of the propositions a generation later; a reprint of the 1986 "No Silver Bullet"; and thoughts today on the 1986 proposition, "There will be no silver bullet within ten years."
Make no mistake, this book is a classic. If you've never read it, you should. Especially if you're a manager of software projects. Or a programmer. Or you use software. Or you're just interested in software. This book is one of the seminal works of modern software engineering.
Not that it's perfect (most of it was, after all, written 2 decades ago, based largely on experience a decade before that). Chapter 7 includes the statements "[Parnas] thesis is that the programmer is most effective if shielded from, rather than exposed to the details of construction of system parts other than his own....While that is definitely sound design, dependence upon its perfect accomplishment is a recipe for disaster." Information hiding (Parnas' thesis) is now considered a cornerstone of good design (and part of the basis for object-oriented design and programming). Brooks points out the original statement in the new chapter 19 and baldly says "Parnas was right, and I was wrong". In doing so he sets an example we would all do well to follow - know when we've made a mistake, acknowledge it, and correct it.
Among the other revelations in the new chapters is something we can take to heart (especially in our contracts!) - the Waterfall method is obsolete for large projects. Incremental builds are better. Not a big surprise if you follow the literature, but it's not the only thing we can learn from Brooks.
Inside the original essays is plenty of truth for us to gnaw on. From "The Tar Pit" and "The Second-System Effect" through "Plan to Throw One Away", and "Sharp Tools" to "Hatching a Catastrophe", Brooks provides us with an incredible collection of myths, proverbs, anecdotes, and just plain tasty thinking to consume. I think each of his essays is worth an evening of its own to make sure you savor it properly (try to pick nights your SO is out so you can do the volume and your relationship justice).
Read this book.
Copyright © Evan Robinson. All Rights Reserved.