Recently I was asked if I could provide a list of some books that I had found most useful to my development as a software practitioner.
I had developed a habit of sitting down and reading a book, away from a computer screen, long before computer screens became locations for reading. I still prefer reading print to reading a screen. I like to be relaxed and able to ensconce myself into the material. That takes a printed book.
Here, I will not list books about specific hot technology topics, such as the latest popular programming language. After you have used a number of languages, and have learned how to categorize them and what problems each may be well suited to, learning the next language is merely to keep up with the game. But some books address issues that are more enduring and independent of specific technologies. First on my list is a book I read early in my career that got me excited about computer theory, that part of computer science which is wholly mathematical and invariant over time.
Algorithmics, The Spirit of Computing 2nd Ed.
1992, by David Harel
If this book doesn’t excite you about algorithms, then you are probably in the wrong field. It presents theory in a readable way. Let Harel tutor you on topics like algorithm efficiency, intractability, and undecidability. It is important to be able to distinguish between the sorts of problems a computer program can solve easily, with difficulty, or not at all.
The Mythical Man Month, Essays on Software Engineering, 2nd Ed
1995, by Frederick P. Brooks
This book is a classic and should be read by every programmer. It demonstrates in a convincing way that developing software is a learning activity that requires close communication between people. “Adding more people to a late project makes it later,” is one of the famous quotes from this book. Find out why this is the case.
The Limits of Software: People, Projects, and Perspectives
1999, by Robert N. Britcher
Insight into fatal problems that can befall a large software project. Learn how the U.S. Federal Aviation Administration’s (FAA) Advanced Automation System (AAS), exemplified “the greatest debacle in the history of organized work.” Rigorous process, diligently applied, resulted in a spectacular failure. Find out why.
The Pragmatic Programmer: From Journeyman to Master
1999, by Andy Hunt and Dave Thomas
A book written by programmers for programmers, this was a game changer. It looked at programming as craft, just around the time that the agile movement got rolling. I had been working in the field for a few years and was coming to the conclusion that programming is an art, especially in the area of code design. It’s key to think about what you are doing and how you could do it better.
Refactoring: Improving the Design of Existing Code
1999, by Martin Fowler, Kent Beck and others.
Pair Programming Illuminated
2002, by Laurie Williams and Robert Kessler
If you want insight into what pair programming is and why it works, this book will help. The ‘synergies’ of pair programming: knowledge sharing, courage to make decisions, etc., become obvious to pair programming practitioners. But they are not obvious to begin with. At the time of this book there existed strong opposition from both managers (‘Why am I paying two people to do the job of one?”) and programmers, (‘I work better by myself.) In truth it had not been tried very much (except see Fred Brooks’ discussion of the use of Pair Architects at IBM.) At this point in time you may not need convincing, if you have tried it. But after you read this book, you may be able to explain the practice to others more effectively.
Agile Software Development, Principles, Patterns, and Practices
2002, by Robert C. Martin
When Object-Oriented Programming became the rage in the 1990’s a number of books came out touting OOP features that were supposed to make program designs easier to decompose. I found that in practice OO was an invitation to bad modeling. My favorite writer on OO is Robert Martin (aka ‘Uncle Bob’). Over the years he has had much to say about the topic.
In this book Uncle Bob instructs you on principles of OO, such as the Open-Closed Principle, Liskov Substitution Principle, Dependency-Inversion Principle and others. He also covers design patterns and goes into some depth about Agile practices.
Agile Software Development: The Cooperative Game, 2nd Ed
2006, by Alistair Cockburn
I came to learn, after a number of years in the field, that one of the biggest obstacles to producing great software systems was dysfunction in the human interactions of all the people involved in a ‘project’. Agile Methodology (as it was known early in the 2000’s) developed as a kind of grass-roots effort to work more effectively. Academics had produced tomes like the Capability Maturity Model, which appealed to management types. Agile and CMM shared a lot of the same goals. But the approach was very different. Some of my favorite books have to do with the practice of development, as opposed to technical topics. This book nailed it for me in many ways. Although it is quite theoretical, I found it very readable.
Practices of an Agile Developer: Working in the Real World
2006, by Venkat Subramaniam and Andy Hunt.
This is an excellent collection of “personal habits, ideas, and approaches of successful agile software developers.” You can read an entire chapter on a lunch break. These are the things you should be doing, and how it feels to do them.
Java Concurrency in Practice
2006, by Brian Goetz
For Java programmers who want to get under the hood and into the Java memory model, nothing beats this book. Many programmers do not understand principles of concurrency and overlook the implications, creating bugs in their programs. (The language Clojure was created largely to make it easier to write correct concurrent programs.) Also see Venkat Subramaniam‘s book on concurrency. You may never again want to try rolling your own concurrency using Java’s low-level support for it after reading these books.
Succeeding with Agile: Software Development Using Scrum
2009, by Mike Cohn
Mike Cohn shares his experiences as a software ‘process’ consultant, working with large companies with deep hierarchies that want to improve their practices. This is an especially good book for anyone managing an agile product, as well as for any member of an agile or scrum team.
The Principles of Product Development Flow: Second Generation Lean Product Development
2009, by Donald G. Reinertsen
I learned about this book at a No Fluff, Just Stuff conference when it was mentioned by one of the participants on an expert discussion panel. If you really want to understand why processes like Scrum are effective, this is the book to read. It is laid out using the mathematics of queuing theory. Keeping the unit of work small and the size of work queues small is key to flow. Understand why Big Design Up Front fails (it’s a huge unit of work). This book is applicable to all sorts of product development efforts (like Scrum) and is not limited to software development.