The best software books

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.

What does refactoring have to do with domain modeling in functional programming?

It turns out that the very essence of code improvement is closely tied to enhancing its capability to handle the intricacies of a specific domain. This implies that even when refactoring a domain-agnostic mechanism in our code, our objective is to address previously inaccessible aspects of the domain.

Another important aspect of refactoring is that functional languages make it more desirable and safer, thanks to core principles such as purity and immutability.

Although there might not be an abundance of books on domain modeling in functional programming, I firmly believe that Fowler's book can be immensely beneficial in this endeavor.

Imagine sitting in a room with 50 of the top software architects in the world and have each of them tell you some brief words of advice about being a software architect.

Welcome to “97 Things Every Software Architect Should Know”. Each 2-page spread features a top software architect offering their advice on some aspect of software architecture. From technical skills to soft skills, this book has it all.

This book is a must-read if you are a software architect, or even thinking about becoming one.

Robert (Uncle Bob) Martin is the recognized go-to person for books on creating quality code. This is the first in a series of books that include The Clean Coder, Clean Architecture, and a number more. His advice and guidance in Clean Code have made a significant difference in my personal coding habits and best practices. This is an indispensable book for all programmers, no matter what they are coding or how much experience they have

Most discussions about requirements focus on functionality, which is what the users most obviously observe in a software system. However, user satisfaction also depends heavily on nonfunctional requirements, such as various quality characteristics the system exhibits: usability, availability, reliability, security, scalability, maintainability, and others.

The Quest for Software Requirements is the only book that focuses on nonfunctional requirements. It provides many questions a business analyst could ask during requirements elicitation to understand the stakeholders’ expectations for those all-important quality attributes. That’s an often-neglected aspect of requirements exploration that frequently leads to deficiencies that can be expensive to correct later in development or after the product is released. This book can help you avoid those unpleasant outcomes.

Why should you spend so much time working on the software architecture of a system? Does it really matter?

This book made me realize that not all systems need the same effort of software architecture to make them successful. If you’re building a doghouse, very little planning is needed—all you need is some wood, nails, a hammer, and a saw. If you are building a skyscraper, you need a significant amount of planning and architecture, or the building will collapse.

In this book the author also talks about risk-based architecture—determining how much architecture is needed based on risk, a perspective I found very helpful in my career as an architect. 

“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.

When trying to become a better Java developer, there is so much to learn.

97 Things covers, well 97, of them in a series of brief essays. What’s cool is that the essays were written by different people so you get lots of points of view on what is important. Topics range from language (comments, fat jars) to the ecosystem (benchmarking, frequent releases) to the language-agnostic (definition of done and breaking down problems.)

Note that two of these are mine. The book is thin at just over 200 pieces. And since each “thing” is short, it’s easy to read on the go.

Another book that predates GitHub but provides a lot of actionable advice today that’s been mostly ignored across much of our industry.

Hard problems like “why isn’t my software project reliable?” are tackled head-on and addressed here. It was an early nudge for me to automate as much as possible in software projects and not ignore difficult problems with project organisation in favour of “fun” technical tasks.

Distributed systems are everywhere now, but long before there were telephony switches, and Erlang was built to make those work.

Reading this book gave me not only an understanding about Erlang, but the language and understanding to talk and think about systems which are distributed from the beginning, not as an afterthought. For me personally Erlang/OTP is the DSL for dystributed system and the patterns implemented have applications every time I think about distributed systems now.

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.

Gerald M. – Jerry – Weinberg is my most-often quoted author.

Having spent more than 50 years in the software world, Jerry was able to write in a timeless manner about the lessons he learned. Over the years, he collected more and more stories he survived from, including all aspects that brings software from an idea to a product that everyone can use.

In this first volume in his Quality Software Management series, he will extend your perspective with Causal-Loop Diagrams and thereby introduce you to the world of Thinking in Systems.

The takeaways from his stories are fostered in easy-to-remember laws and principles that he gives you as a free takeaway summary in the end as well. Extend your perspective on managing for quality rather than staying oblivious.

This book provides a brief introduction to the concept of algorithms before discussing the limitations of computation. Specifically, Harel explains undecidable problems (that is, problems for which no algorithm exists) and infeasible problems (that is, problems for which only algorithms are known that have an exponential runtime). I like this book (and its splendid title) because of its focus on the limitations of computation. Harel does a marvelous job in explaining two difficult topics about computation. The understanding of any scientific discipline requires the understanding of its limits, and the limits of computation are as significant as they are surprising.

Gary McGraw has been an advocate for the importance of developing secure software during the more than 15 years that I have known him, and before that! He has written a number of books, but this one captures his philosophy on how to develop secure software. It’s an excellent resource for practitioners and management.

The second book from Gregory and Crispin brought me up-to-date on the different trends in the Agile world, ten years after having delved into their first book.

How do you share the quality mindset in a DevOps culture? What about Design Thinking? With many more examples from the industry, the two authors made me curious about some of the things that I had ignored until I read their book.

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.

This book is the software industry’s “bible” on how to start software development projects. 

It explains how to conduct up-front user research, before design, prototyping, and coding start. User research, followed by analysis of your findings, is how you determine requirements and figure out what features or improvements are needed and which are most important. 

This book presents a collection of methods for doing that. You probably won’t need every method described this book on every project, but having Holtzblatt and Beyer’s toolkit of user-research and analysis methods available when needed is valuable. 

I read it several times, and now several of its methods are baked into my normal design process.

Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.

This book is set in the same universe as The Phoenix Project and The Unicorn Project, but it's at a new company named investments unlimited.

It's also a fictitious story, but with all brand new characters, and brand new problems! In this book they cover security much more deeply than any of the other previous books, talking about how compliance and audit can work together with the information security and DevOps teams.

They talk about common problems that I have faced in many organizations, and a lot of the stories feel so familiar I wonder if the authors have followed me around throughout my career.

Although of course they save the day in the end, there are many parts of the book where we're not quite sure if they're going to make it or not with various characters learning to see things in new ways, so that they can make… show more.

This is from an older generation of open source development, pre-GitHub, but much of the advice here is still incredibly relevant and astute today, helping provide advice on the interpersonal as well as technical sides to open source development.

Many of the underlying principles from this book are what form my grounding as an open-source maintainer for the last 15 years.