The most recommended software books

While this book was still in the writing, Crispin and Gregory published draft chapters on the internet.

At the time, I read them, and managed to introduce many of the great insights into my own work. Even though I was working in a more traditional environment, the ideas from the two ladies inspired me on my journey to the agile methodologies.

I even managed to contribute some of my own real-world examples from my own experiences to their writings – and they decided to include some of them.

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.

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.

Many of us have fully embraced agile programming, but doing it well, really well, requires discipline. In Clean Agile a number of world-class programmers discuss what it takes to put Agile programming into practice with y our team. This book has made me a much more “agile” agile programmer, and the section on SCRUM is worth the price of the book.

In addition to Java, you need to know about the Java ecosystem.

Each chapter covers a type of tool like version control, securing binaries, or mobile. Some chapters cover a variety of tools. I particularly liked the overview of Quarkus and Micronaut. I also liked the emphasis of tools vs a role. The analogies were great such as comparing identify/fix/deploy to an oil spill.

The book is 300 pages and easy to carry around. Despite having four authors, the book is very cohesive and reads well.

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.

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.

Of all the books I recommend, this is practically a sort of personal bible, which I very frequently consult.

This book doesn't just show you how to code; with realistic patterns and real-world examples, it's like having experienced mentors guiding your every keystroke. These patterns aren't just snippets; they're blueprints for building robust, flexible software.

I think the book is practically mandatory for all developers, novice or seasoned. It transformed how I approach problems, teaching me techniques I use daily in systems design and development.

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.

There are many creative professions where the performers practice their skills more often compared to the actual time they do the actual work.

Software development is widely considered as a creative profession. Unfortunately, it doesn’t fall into the category of professions where its practitioners hone their skills. This book discusses a coaching strategy where software teams can periodically practice and improve their technical practices.

“Samman” is the Swedish word for “together”. Organisations that invest in technical coaching increase their business success. This book is a real eye-opener for anyone who likes to improve their approach to team coaching. It lays out the groundwork for improving the technical practices of software teams.