Two Musts for Every Programmer's Library

Solid principles little changed in 25 years
by Conrad Weisert, November 2004

Surprisingly little has changed in principles of program design since Glen Myers wrote his aclaimed book during the height of the "structured revolution". Steve McConnell echoes most of Myers's advice on component coupling and module cohesion ("strength") as well as the stepwise refinement process. Despite the age of Composite Structured Design there's virtually nothing in it that doesn't apply to today's software development milieu, and every programmer or software engineer should master it.

Of course, Myers didn't know about classes and objects, which are the focus of McConnell's volume. McConnell assumes that the reader understands and intends to practice object-oriented design. His examples are in C++, Java, and occasionally Microsoft's proprietary Visual Basic.

The popular complaint against the Myers book was that it introduced too much new terminology, some of which wasn't really needed, for example seven named varieties of component coupling. Now that we've become accustomed to those terms, they no longer seem difficult or unnecessary.

The main complaint against McConnell's book will probably be about its length. It takes a long time to read through it sequentially, and it doesn't lend itself, on first reading, to selective browsing. The style is friendly and readable, however, so reading the whole book is a pleasant chore. I managed to digest it over several days on the Chicago subway.

I mildly regret that examples in some parts of the book don't always practice what McConnell preaches in other parts (a common flaw in programming texts). In particular, the author doesn't always exploit object-orientation when it's called for, a shortcoming I noted in a recent article on string handling by Koenig and Moo. If you're an experienced senior programmer, you'll probably disagree with some of his advice, but you'll surely find the great bulk of it reinforcing your views, and you'll want to recommend it to your less experienced colleagues.

Some major pluses I was especially pleased by Steve McConnell's resistance to the more extreme forms of today's fad methodologies and insider snobbery. For example: He firmly supports rigorous requirements without burdening the reader with his own views on the form those requirements should take or the process by which they should be developed. He warns strongly against the sort of hacking that characterizes some of the agile methodologies. He advises against overcomplication, such as reference counted container copying that others, such as Coplien consider essential. He doesn't echo the common sneering condescension toward preprocessor macros. Mr. McConnell's emphasis is on good practice and quality throughout, as it should be.

and a few minor minuses Since I was extremely critical of another book for similar flaws, fairness requires that I point out two minor gaffes in Chapter 17's discussion of recursion: The explanation of Quicksort on page 394 will seriously confuse the reader who isn't already well-acquainted with it. To say merely that the unseen Partition() routine "chops an array in two" omits the main point, i.e. how elements actually get moved. An author must be especially careful when he condemns a programmer's work. "If a programmer who worked for me used recursion to compute a factorial, I'd hire someone else." -- p. 397 Unfortunately, Mr. McConnell then offers an equally inappropriate iterative solution that would lead me to hire someone else. (When you compute n! you also recompute every smaller factorial. All the possible factorial results fit easily in a table.)

Both highly recommended

Return to book reviews.
Return to table of contents.