33.1 The Library of a Software ProfessionalBecause this book describes hundreds of other books and articles that contain information on software development, it's hard to know what to read first. A software-development library is made up of several kinds of information. A core of programming books explains fundamental concepts of effective programming. Ancillary software-context books explain the larger technical, management, and intellectual context within which programming occurs. And detailed references on the languages, operating systems, environments, and hardware contain information that's useful for specific projects. Books in the last category generally have a life span of about one project; they're more temporary and aren't discussed here. Of the other kinds of books, it's useful to have a core set that discusses each of the major software-development activities in depth-books on analysis, design, construction, management, and testing. Top-Ten ListThe following books make up a solid foundation for a software professional's library. 1. The Psychology of Computer Programming. Gerald Weinberg's The Psychology of Computer Programming (1971) is packed with fascinating anecdotes about programming. It's far-ranging because it was written at a time when anything related to software was considered to be programming. The advice in the original review of the book in the ACM Computing Reviews is as true today as when the review was written:
If you can't find The Psychology of Computer Programming, look for The Mythical Man-Month (Brooks 1975) or PeopleWare (DeMarco and Lister 1987). They both drive home the theme that programming is first and foremost something done by people and only secondarily something that happens to involve computers. 2. Programming Pearls. Jon Bentley's Programming Pearls (1986) is the first of a pair of books with "Programming Pearls" in the title. It's a vigorous discussion of programming that articulates the reasons that some of us find programming so interesting. The fact that the information isn't comprehensive or rigidly organized doesn't prevent it from conveying powerful insights that you'll read in a few minutes and use for many years. Another excellent book in the same spirit by the same author is Writing Efficient Programs (Bentley 1982). It's a nearly exhaustive treatment of code tuning with loads of examples. Although Bentley doesn't present many more techniques than Chapters 28 and 29 of this book, he's a master of interesting examples and supports his code-tuning techniques with many memorable anecdotes. 3. Classics in Software Engineering. Ed Yourdon's Classics in Software Engineering (1979) is a collection of the classic, seminal papers in software engineering. Every programmer should read Dijkstra's papers, "Go To Statement Considered Harmful" and "The Humble Programmer" along with several others. They contain in a nutshell the accumulated wisdom of the programming community as of about 1975. 4. Principles of Software Engineering Management. Even if you plan to avoid management for your entire career, it's a good idea to learn something about it for two reasons. It gives you insight into what your manager does (or what your manager should do), and it helps you to self-manage your own projects. Tom Gilb's Principles of Software Engineering Management (1988) is a good place to start. Gilb is a good writer, a metrics hot shot, and a master of quantitative approaches to management. He is keenly aware of leading-edge approaches. After the first couple of chapters, you can pick and choose your way through his book. Tom DeMarco's Controlling Software Projects (1982) is a good alternative to Gilb's book. DeMarco also takes a quantitative approach, and both he and Gilb are somewhat uncommon in that they both emphasize controlling projects rather than predicting what they will do. 5. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. The first book on structured design was Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design (Yourdon and Constantine 1979). It was cowritten by Larry Constantine, who developed most of the key ideas in the structured-design approach. Other books have provided easier explanations, but this book is readable enough, and you can't beat hearing about a body of ideas from the person who came up with them. A good companion to Structured Design is Object Oriented Design with Applications (Booch 1991). Even though object-oriented design doesn't yet have the track record that structured design has, it seems to be truly useful in composing systems at a higher level of abstraction than structured design allows. Booch is a pioneer in Ada and object-oriented methods, and his experience shows throughout this book. 6. The Art of Software Testing. Every programmer should have a book on testing. This isn't to say that testing is the most valuable quality-assurance topic overall--just that testing is something a programmer should understand. Glenford Myers' The Art of Software Testing (1979) was the first book devoted to the topic and is still one of the best. If you can't find it, a good alternative is Bill Hetzel's Complete Guide to Software Testing (1988). In addition to the specific books in the first part of this top-ten list, you should have books that cover these general topics. 7. A book on requirements analysis. You have a choice among several first-rate books on requirements analysis. The first excellent book on the topic was Tom DeMarco's Structured Analysis and Systems Specification: Tools and Techniques. A more recent treatment is Ed Yourdon's Modern Structured Analysis (Yourdon 1989a). For real-time programmers, Strategies for Real-Time System Specification (Hatley and Pirbhai 1988) is a good choice. Once you've read the standard analysis books, check out Gerald Weinberg's Rethinking Systems Analysis and Design for its entertaining departures from the conventional wisdom. 8. A book on quantitative project-planning and productivity. After years of wondering why no one was coming up with quantitative data about software-development methods, I read a paper by Barry Boehm that made it unmistakably clear that someone was coming up with such data. If I could have only one software-engineering reference book, it would be Boehm's Software Engineering Economics (1981). Ostensibly about how to do estimates for software projects-work months, number of programmers, calendar time, manpower loading, and so on-- it describes just about every important factor that goes into making software productive or unproductive. Boehm has a passion for quantitative data, and he has summarized most of it in this volume. Don't be put off by its size or the enormous number of charts and tables. You don't need to read most of them, but they'll be there whenever you're curious. Try starting with Section 33.6, "Personnel Attributes," which gives a pointedly human overview of the reasons that software-project estimation has so much variation and unpredictability. For a short introduction to the same information, see Boehm's paper, "Software Engineering Economics" (1984). A good companion or alternative to Boehm's book is Applied Software Measurement (Jones 1991). Capers Jones is just as dedicated to the quest for quantitative data as Boehm, and you could view his book as an updated subset of the information in Boehm's. Chapter 3 on United States averages for software productivity and quality is especially fascinating. Jones's earlier book, Programming Productivity (1986) is just as interesting but has been superseded to some extent by the publication of his more recent book. 9. A book on data structures and algorithms. Every programmer should have a good book on data structures and algorithms. It's better to pull clever algorithms out of a book than to invent them yourself. The advantages are (1) that you know the algorithm works and (2) that it probably works better than any you'd have time to come up with. Robert Sedgewick's Algorithms (1988) is one good choice. Others are Data Structures (Reingold and Hansen 1983) and the three volumes of Donald Knuth's The Art of Computer Programming (1973a, 1973b, 1981). 10. An overview of the software-development process. It's useful to know what a software-development cycle looks like from a larger perspective. If you've been all the way through a few smaller projects, you might have an intuitive sense of it. If you've worked on smaller parts of large projects, you might have no sense of it at all. One excellent overview is Wicked Problems, Righteous Solutions (DeGrace and Stahl 1990), a catalog of software lifecycles. The authors cover this relatively small topic thoroughly and include lots of tables and diagrams. In exposing you to several different project lifecycles, the book gives you a good perspective on planning and analyzing your own projects or other people's. A second choice, covering different ground, is Watts Humphrey's Managing the Software Process (1989). Humphrey describes software development as a process and outlines the activities in each of its parts. Unlike DeGrace and Stahl, Humphrey offers firm opinions about which processes are better than others, but you'll get the big picture from either book. For an even broader view, not of software processes but about how software processes come into being, take a look at Fred Brooks's "No Silver Bullets-Essence and Accidents of Software Engineering" (1987). It's a witty and informative discussion of what's needed to improve software development now that all the really big improvements have already been made. This material is Copyright © 1993 by Steven C. McConnell. All Rights Reserved.
|
Email me at stevemcc@construx.com.