|
|
|
I ultimately judge books the same way I judge movies, not by the good feeling I have as I come to the last page, but by how much I'm still thinking about the book a week, a month, or a year later. By that measure, here are my top software development books.
Programming Pearls (Jon Bentley). This book provides terrific insight into the functioning of the expert programmer's mind. In each essay, Bentley walks the reader through the thought processes he uses to solve detailed programming problems. Along the way he introduces the concepts of Big-O notation, approaches to performance tuning, back-of-the-envelope calculations, and many other topics. Reading this book thoughtfully is like working through an apprenticeship with a master programmer. Almost as good for the same reasons is P. J. Plauger's Programming on Purpose: Essays on Software Design. Wicked Problems, Righteous Solutions (Peter DeGrace and Leslie Stahl). I liked this book from the start, and the longer I've considered its ideas the more important the book seems. The book describes life cycle models such as waterfall, evolutionary prototyping, scrum development, and so on. Projects that choose the wrong lifecycle model for their specific needs will face an uphill battle and risk not finishing at all. For gaining a big-picture understanding of how software projects, work, this book is hard to beat. The Psychology of Computer Programming (Gerald M. Weinberg). This book is packed with fascinating anecdotes about programming. Long before the term "peopleware" was coined, Weinberg was conducting an in-depth exploration of computer programming as something done first and foremost by human beings, and only secondarily as something that happened to involve computers. The sentiment expressed in the original review of the book in the ACM Computing Reviews is as true today as when it was written:
Mythical Man-Month, 2d Ed. (Frederick P. Brooks). The Mythical Man-Month is probably the most cited software engineering book of all time, but I probably wouldn't have included the first edition in my top 10 list. It made enjoyable reading and I would recommend it as part of any professional software developer's library, but I wouldn't have put it in my top 10. The second edition makes it into the top 10 for two reasons. First, Brooks candidly assesses the parts of MM-M he thinks are still right after 20 years and parts that he now thinks were wrong. His evaluations of his original positions and explanations of why he thinks they were right and wrong are fascinating. Second, the revised edition include Brooks' incredible "No Silver Bullets" paper, which is shaping up to be one of the most insightful papers of the 1980s. Conceptual Blockbusting (James L. Adams). I learned more about software design from Conceptual Blockbusting than from any of the many books I've read that focus specifically on software design. Software design books seem to focus exclusively on the activity of partitioning a system up into pieces, giving guidelines for how to evaluate a particular partitioning. They generally ignore aspects of design such as algorithm development and the process of coming up with the partitioning in the first place. These are the areas in which Conceptual Blockbusting excels. Adams is an engineering professor at Stanford and teaches an engineering design course, so this book's content is on target for software developers. How to Solve It (G. Polya). This book is essentially 1945's version of David Parnas and Paul Clement's paper, "A Rational Design Process: How and Why to Fake It" (IEEE Transactions on Software Engineering, February 1986, pp. 251-257). Polya's book is about mathematical theorems, but if you replace "mathematical theorem" with "software design," the book is an outstanding software design book. Polya points out that the process used to create a design is different than the process used to explain it. The explanation should be neat and orderly, progressing in an orderly way from premises to conclusions. The creation of the design is hardly so tidy. The designer creates designs that don't work, explores dead ends, and throws away more work than he keeps. Like Conceptual Blockbusting, I think this book sheds more light on the activity of software design (as opposed to the result) than any software design book I've seen. Peopleware (Tom DeMarco and Timothy Lister). The genesis of Peopleware was an obscure 1985 paper called "Programmer Performance and the Effects of the Workplace" (Proceedings of the 8th International Conference on Software Engineering, August 1985, pp. 268-272). The 1985 paper contains a higher information-to-explanation ratio than the book, and I think in some ways it is more interesting. The book is also mis-subtitled. The subtitle says it's about "productive projects and teams," but the discussion of teams is only 35 pages long, and the book is probably better known for its coverage of the effects of work environment on productivity. Do these points detract from the book? Not at all. The main message of this book is that software is something that is constructed by people, and if you want good software, you'd better look out for the welfare of the people creating it. Peopleware said that first and still says it best. Software Engineering Economics (Barry W. Boehm). This book is mostly about estimating and managing software projects using quantitative approaches, but along the way Boehm covers a wide variety of other topics including the importance of management and, my favorite, Section 33.6, "Personnel Attributes," which gives a pointedly human overview of the reasons that software-project estimation contains so much variation and unpredictability. Measures for Excellence (Lawrence H. Putnam and Ware Myers). In this book Putnam and Myers present a full-fledged software project estimation methodology. The content in the book is dense, like a math text, and some of the diagrams become understandable only after very careful study. But the book is worth the price for a variety of reasons. The early part of the book explains how conceptual work like software development has been found to progress according to a mathematical curve known as the Rayleigh distribution. The effort you put into understanding this formula pays big dividends in understanding what happens when you try to compress a software schedule, add people to a late project, estimate new projects, and so on. Chapter 14, "A Very Simple Software Estimating System," is a gem that explains how to calibrate a simple cost-estimation model to your organization and how to use it to estimate medium to large projects. The estimation method Boehm describes in Software Engineering Economics is well-developed and in widespread use. It's recently been updated and improved with the publication of Cocomo II, but for reasons that become clear in studying Measures for Excellence, I think Putnam's estimation model is the model with more substance. Assessment and Control of Software Risks (Capers Jones). Jones set out to catalog the major risks that affect software projects in a systematic, reference format that includes a description of each risk, severity, methods of prevention, and methods of control. Jones follows this format in describing 60 specific risks, and he is to be commended for being one of the earliest people to spot widespread software phenomenon such as excessive schedule pressure, management malpractice, and many of the other risks he discusses. I have to disclose that I have a love/hate relationship with this book, which I give an A+ for concept and a B- for execution. From a practical viewpoint, the most useful sections are the methods of prevention and control, and the control sections tend to be skimpy. For example, for the risk of creeping requirements the book discusses only requirements gathering and specification techniques (prototyping, JAD, etc.), but it doesn't discuss downstream control methods such as change boards, triage, and so on. At a more fundamental level, the book is marred by lack of consistent definition of exactly what a "risk" is. Some of the book's risks apply to individual projects, some to whole organizations, and some to the software industry at large. The typical definition of risk is "undesirable outcome," and many of the risks listed seem to confuse cause and effect. Is "inadequate software engineering curriculum" an undesirable outcome? How about "false productivity claims?" Jones' frequent polemics against lines of code metrics, the Software Engineering Institute, and companies that don't have full-fledged metrics programs detract from some of the book's important messages. In spite of its weaknesses, this is an important book and easily qualifies for my top 10. Software Creativity (Robert L. Glass). This 1995 book should have been the breakthrough book that explored a little discussed and less understood aspect of software development: the role of creativity. Glass discusses creativity versus discipline, theory versus practice, heuristics versus methodology, process versus product, and many of the other dichotomies that define the software field. This book should have been the breakthrough book for creativity that Peopleware was for human factors. Regrettably, the book is now listed as out of print. I encourage you to call Prentice-Hall PTR (800-811-0912) and tell them you'd like to see this book reprinted. This material is Copyright © 1998 by Steven C. McConnell. All Rights Reserved. Steve's Home Page
|
Email me at stevemcc@construx.com.