An OO-Design Reading List

Justin Kruger and David Dunning's Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments (Journal of Personality and Social Psychology 77:6 [Dec. 1999], pp. 1121-1134) discusses both why people are unable to recognize their own incompetence and why people defend their incompetence so tenaciously. This paper has rolled off the APA web site, but here's a Scanned Version, and here's a more readable PDF version, but with smaller tables. There's also a write up on Wikipedia. Also of interest is Ehrlinger et al's Why the unskilled are unaware: Further explorations of (absent) self-insight among the incompetent.

In their words:

...consider the ability to write grammatical English. The skills that enable one to construct a grammatical sentence are the same skills necessary to recognize a grammatical sentence, and thus are the same skills necessary to determine if a grammatical mistake has been made. In short, the same knowledge that underlies the ability to produce correct judgment is also the knowledge that underlies the ability to recognize correct judgment. To lack the former is to be deficient in the latter.

This book, Self-Insight: Roadblocks and Detours on the Path to Knowing Thyself, provides a synopsis of this work along with a discussions of related problems, like: why is so hard to come up with an accurate estimate? It's an essential read.

Everett Rogers's, Diffusion of Innovations discusses two essential problems: (1) Why is it that new ways of doing things are not adopted, even though it's obvious to everyone that the new way is better, and (2) how do you go about bringing about that adoption. That is, how does an innovative technique infuse an organization (or not). This is an academic book, but is, nonetheless, an enjoyable read, full of useful insights.

Edward Tufte's The Visual Display of Quantitative Information is a spectacular book. It discusses how to present numbers in such a way that their meaning is clear. This clarity is an essential component in a decent UI, particularly in reports and other output. If a user has to pull out a calculator or draw a picture to make sense of the output your program presents, then there's something wrong with your UI. People use your program because they want an answer to a particular question. You should provide them with that answer, not with the wherewithal they need to find the answer. This book shows you how to create output that's actually useful. Tufte's other books Visual Explanations and Envisioning Information are also very good. It's worth owing all three.

Larry Constantine and Lucy Lockwood's Software for Use is about the important parts of UI design — things like flow, page organization, usability, and so forth. This is not a book about art; rather it shows you how to create a very usable interfaces, and along the way, design programs that actually do something useful. The result of their process is an "abstract" UI design that shows you what goes on the page and where, and defines the movement between pages. This sort of "abstract" design is ideal for use in the design process. You can give the abstract model to a graphic artist to make it look pretty.

Constantine and Lockwood's approach is based primarily on use-case analysis, which is also a fundamental part of developing your object model. That is, they identify the fundamental tasks that the program has to accomplish, and then design a UI that walks you through those tasks in an efficient way. By basing the UI design on the use cases, you guarantee a coherent integration of the user interface and the object model that makes the program easier to build and maintain as well. The UI is not a veneer on the top of the code, it's a visual representation of the code itself.

You should also check out the authors' web site www.foruse.com, which has lots of links to other UI-related books, etc.

See Also: Alistair Cockburn's Writing Effective use Cases, below.

Donald Norman's "Design of Everyday Things" is the classic book on design for usability. It explains how to design, not just software, but things in general, so that their use is easy and intuitive. The principles in this book are universal.

Alan Cooper is the inventor of Visual Basic. Though I disagree with him about a lot of stuff (e.g. Visual Basic), he's done a lot of great UI-design work. One of his most important ideas is the notion of "goal-directed design," where you consider your user's implicit goals as an integral part of the design process. The idea is expounded in Goal-Directed Software Design from Dr.Dobb's Journal, July 2001 (originally in the Sept., 1996 issue). [Alan's company site]

Rebbecca Wirfs-Brock is one of the pioneers of OO Design. Her Object Design: Roles, Responsibilities, and Collaborations covers her most recent thinking on the design process. Wirfs-Brock uses CRC cards as a means of defining objects, and her methodology gets you to focus, correctly, on what an object does rather than what it contains. Most precisely, she emphasizes the notion of defining an object by its set of responsibilities defined in a "class contract," Essential concepts that most people who think they know OO simply because they know an OO language don't understand adequately.

Even if you're using a different methodology, you'll find the insights in this book useful. If you're coming from a procedural background, this book can help shake you out of the fundamentally incorrect object-as-bag-of-data-with-intelligent-warts mindset.

Arthur Riel's Object-Oriented Design Heuristics teaches the difference between a good and a bad OO design. It's approach is to present a set of 60 rules of thumb that, if followed, will lead towards a good design. Reil talks a lot about both class structure and object interaction. The book not only presents the rules, but also talks extensively about what the rule accomplishes—an essential component of a book of this sort. Simply following rules by rote, without an understanding of why the rule exists, will not get you very far.

Martin Fowler's UML Distilled, 3rd Edition is a much better presentation of UML than the actual standard document (listed below). It's concise and to the point, but has enough explanation that you understand what the notation actually does.

Also of interest is Miles and Hamilton's Learning UML 2.0 which is less of a reference and more of a textbook, so provides a gentler introduction to UML, than UML Distilled.

Get the UML 2.5 Standard (along with a bunch of other useful stuff) from OMG at http://www.uml.org. The UML Superstructure document is the one that actually describes the notation. This document is, even by the standards of a "standard," very poorly written. It's 600+ page bulk could easily be reduced to about 50 easy-to-read pages. However, It is the official standard, for what that's worth.

Use-case analysis is an essential part of every OO-Design methodology. Alistair Cockburn's Writing Effective Use Cases is the best book going on how to assemble and work with use cases. It takes a practical approach the the subject that's both refreshing and usable. It's a good complement to Constantine and Lockwood (above).

Boehm and Turner's Balancing Agility and Discipline is a good discussion of the benefits and problems associated with both Agile and heavyweight development methodologies. They try to come up with a balanced approach that leverages the best characteristics of both approaches.

Kent Beck's Extreme Programming Explained started a revolution in software development. It was the first book anyone had seen on an Agile-development methodology, and was extremely controversial. Extreme Programming (XP) is still controversial, particularly in its insistence that the only real documentation you need is the code itself, and that up-front design should be avoided. Nonetheless, there's a lot of great stuff in this book—practices, the adoption of which would benefit even a hard-core heavyweight-process shop.

I think one of the biggest problems with this book is that Beck assumes that the reader is knowledgeable of good OO technique and structure. Its bibliography lists many books that should actually be prerequisites to this one. (That bibliography, by the way, is exemplary.) Someone who doesn't have these prerequisites could easily jump to the wrong conclusions. For example, Beck assumes that you're doing something like use-case analysis to come up with XP "stories." An inexperienced reader wouldn't know that, however, and might even skip requirements gathering entirely, since Beck doesn't discuss it.

At the center of all the Agile processes is the notion of test-driven design (TDD): writing the tests before you write the code, and running the tests as often as every few minutes. Steve Freeman's Growing Object-Oriented Software, Guided by Tests is maybe the best book on the subject. Not only does he cover how to do TDD, but he explains how to do it in a way that makes your system better from an object-oriented perspective. That is, it's a book that's as much about design as it is about testing. The book also shows you how to do TDD with a full-blown real-world example presented in depth.

Robert ("Uncle Bob") Martin's Agile Software Development is probably a better introduction to Agile techniques than Kent Beck's book. Martin doesn't gloss over the details as much as Beck, and there are several valuable step-by-step walkthroughs of the development process. There's a lot of great advice in here that's entirely missing from Beck's book.

Jacobson, Booch, and Rumbaugh's The Unified Software Development Process describes the best of the formal development methodologies. In a remarkable marketing coup, IBM's Rational Software has managed to get everyone to call the process the "Rational Unified Process" (RUP), but the process has nothing to do with IBM/Rational. I'm not satisfied with any of the RUP-Explained or RUP-Distilled books, so you may as well go to the horse's mouth. The book is a bit dry, but it's thorough.

Craig Larman's Applying UML and Patterns bears the same relationship to the Booch Unified-Process book that Martin's book does to Beck's Extreme-Programming book. That is, it shows you the Unified Process in action, taking you step by step through the evolution of a design, talking about the problems you might encounter along the way.

Refactoring — the process of improving the quality of code without changing the way the code works — is an essential part of the development process. Martin Fowler's Refactoring: Improving the Design of Existing Code is a valuable catalog of programming "bad smells" and how to fix them. Reading this book will not only show you how to fix problems in the code you wrote before you knew what you were doing, but will help you not make the mistakes in the first place.

My own book, Holub on Patterns: "Unlike the majority of books on design patterns in software, this one is not structured around a series of stand-alone patterns that exist in splendid isolation. Where most patterns books are catalogs of varying degrees of complexity, this one is heavily code-centric and seeks to show patterns as they exist in the wild. This makes for a much more complex and demanding read but it's necessary because the real world is much messier than the relatively simplistic world that emerges from the relatively simple examples in many design patterns texts. There's no doubt that there's a big gap between an intellectual understanding of patterns and being able to recognize when and where to use them in your own code. This is the gap that Allen Holub aims to bridge with this book." (From the review on TechBookReport )

James Edward Gray also reviewed the book on Slashdot.

Design Patterns, by Gamma, Helms, Johnston, and Vlissides (otherwise known as the "Gang of Four"), is the classic catalog of design patterns that started off the whole movement. It's one of the most important CS books written in the past 20 years. Though the book is academic in its treatment, it's thorough in its coverage. My book, Holub on Patterns, covers the same material, but with a more practical emphasis.

The Pattern Languages of Program Design books books are the collected proceedings of the periodic "PLoP" conferences, one of the main events in the design-patterns world. Together, they represent a vast repository of patterns not covered in the Gang-of-Four book, in problem areas ranging from threading to client-server systems. All five books are well worth your time. The link at left gets you to the Amazon page for the first volume, but here are links to vol. 1, vol. 2, vol. 3, vol. 4, and vol. 5.

Martin Fowler's Patterns of Enterprise Application Architecture focuses on patterns that come up in large Enterprise-level programs (as compared to the other books in this section, which address more general problems that are likely to come up in any program). It's an essential book for anyone who is working on very large systems.

Buschmann et al's Pattern Oriented Software Architecture: A System of Patterns is focused more on architecture than on individual patterns. That is, the book concerns itself with how several patterns work together in concert to solve bigger problems than do the individual patterns in isolation. This book is one of the few that describes the the Presentation-Abstraction-Control (PAC) architecture that I've talked about extensively in articles on alternatives to Model-View-Controller.

Volume 2, Patterns for Concurrent and Networked Objects, is also good.

Refactoring to Patterns Martin Fowler's Refactoring, discussed above, is the essential introduction to the refactoring process. Joshua Kerievsky's Refactoring to Patterns focuses on refactoring existing ad-hoc code into code that uses the Gang-of-Four design patterns. That is, once you learn the patterns, you tend to see all the places in your existing code where you could have used them, but didn't. Kerievsky shows you how to fix that less-than-ideal code.

C. Northcote Parkinson's Parkinson's Law states: "Work expands to fill the time available for its completion." This is a funny, and at the same time pointed, discussion of why most organizations aren't able to reign in out-of-control projects.

The Mythical Man-Month is a classic, written by Fred Brooks to summarize the issues that arose when he led the OS/360 project for IBM. This is the book where "Brook's Law" ("adding manpower to a late software project makes it later") comes from, but it holds a lot of other pithy observations as well. The book is every bit as relevant today as it was when it was written in the late 70s. This edition contains the full text of the wonderful "No Silver Bullet" essay, from Computer Magazine (April 1987)

Just about everything that Tom Demarco's written is worth reading. His Peopleware, however, is the quintessential book on software-project management. Everybody should read it. Period.