100 books like A Philosophy of Software Design

I learned my first programming language as a kid, and Basic always felt like a beginner’s language. It wasn’t until I started writing C that I felt in control of the machine. This book is a classic and was on every C-programmer’s shelf in the 80s and 90s. It isn’t the easiest read but is remarkably comprehensive for a relatively thin volume. The fact that it has been in print for over 30 years tells you something about its staying power.

Nowadays, I tend to code in higher level languages, but every once and a while I dip down, getting closer to the bare metal, and brush this baby off. It is probably one of my most well-worn books.

When I work with students new to programming I often find they struggle with translating the toy problems in exercises to actually doing something in the real world.

I love this book and frequently recommend it to new programmers because it is centered around problems. Coding should be about making your life easier. At the beginning, the problems are small, but by the end, you’re learning about email, PDFs, and GUIs.

Sweigart has a great voice, and reading this feels like being guided by a friend rather than yet another coding textbook.

When helping software organizations be nimbler, I tend to stress two things: release more frequently and automate everything. Over the years, I’ve frequently got pushback from the database folks. Most DBAs and Data Architects are taught a very top-down approach and want all information upfront before creating a single table.

This book teaches how to apply abstraction layers that are common in programming but not as common in database design. The book showed me how to use versioned views to control the coding interface and upended my overall approach to designing databases.

Most of the code I write and use is open source. As a programmer, it is easy to think “open source means free.” I didn’t think much about it until one of the companies I worked at got acquired, and we had to audit our licenses.

The big company that bought us was very particular about which licenses were compatible with their needs. That was when I realized I needed to understand this stuff better. Rosen does a great job of teaching what is otherwise legalese in plain-spoken, easy-to-understand language. This book taught me why I choose the licenses I do rather than picking blindly.

If you check out Amazon’s best selling books on object-oriented design, you might see a relic from 1995 still hanging near the top: "Design Patterns". That book transformed software design. Its four authors will forever be known to my generation as the “Gang of Four".

Some of the original patterns may feel outdated today, but others remain essential. Pity that the book itself is such a tough read. Good thing that another "gang of four”, spearheaded by the excellent Kathy Sierra, gave us this lighthearted take on the original patterns.

The Design Patterns book was a densely packed truck of ideas. By comparison, Head First Design Patterns is a whimsical bumper car. It’s quirky and accessible, which some serious programmers found off-putting: “It’s a book for teenagers!“, they griped.

Yes, it’s not for everybody. But it’s fun, unassuming, and it teaches important concepts. So it makes my list.

“Good agile testing is good context-driven testing applied in an agile context.”

The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.

These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.

Exploring requirements is more about communication than computing. Requirements elicitation often involves discussions between business analysts and user representatives or other project stakeholders in either one-on-one discussions or group workshops. Requirements by Collaboration presents a wealth of practical tools and techniques for planning and leading requirements development workshops. It’s packed full of useful tips, checklists, questions to ask, and activities to perform to make workshops effective and successful.

I especially like Gottesdiener’s “collaboration patterns,” eight techniques that a workshop facilitator can employ to help the group achieve its objectives. The pattern called Decide How to Decide is the first one that any group of collaborators should use: exactly how will we make decisions? If you expect to lead, or even participate in, requirements workshops, read this book first.

Software engineering involves several phases such as requirements gathering, design, programming, testing, and deployment.

This book explains techniques that allow you to build quality and robustness into every phase of the process. It discusses design, classes, defensive programming, collaboration, refactoring, and more.

The book uses many examples in an assortment of languages but the concepts apply to any programming language. In fact, the main themes like building error detection into every step of the process generalize to even non-programming parts of the development process.

If you’re an experienced developer, you may have discovered some of this book’s ideas elsewhere or even on your own, but you only need to pick up one or two new tidbits to make the book worthwhile.

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.

One way to craft lessons learned is in the form of recommended best practices (or, as I prefer, “good practices”). Best practices represent collected and distilled wisdom from many observers, many projects, and many years of experience. Rapid Development includes 27 best practices for software development, with one chapter devoted to each. Although the book was published more than 25 years ago, most of these are still relevant. Indeed, several of them have been incorporated into routine contemporary practices: evolutionary delivery, designing for change, timebox development, and requirements scrubbing. Techniques such as inspections, miniature milestones, principled negotiation, and reuse are perennially pertinent.