I’ve been a software architect for a very long time. I love hard problems, and I’m very passionate about collaborating with others to find the right solution to them. Software architecture is a challenging, multi-faceted discipline with very few resources to help you make the right decisions. That’s why I’m recommending these books on software architecture. These books helped me become a more effective software architect, and I hope they can help you become more effective as well.
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.
Defining and managing the requirements for a software system is hard! I’ve been interested in improving how projects handle their requirements for more than 35 years. I realized how important this was when I saw how many projects—including my own—struggled and failed when they neglected to build a solid foundation of well-understood and clearly communicated requirements. I’ve personally used nearly all of the techniques described in my book Software Requirements, and I got always better results when I applied those techniques. My books, articles, training courses, presentations, and videos on requirements have been helpful to thousands of business analysts worldwide for many years.
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.
"I spend much time helping organizations capture requirements and even more time helping them recover from not capturing requirements. Many of them have gone through some motions regarding requirements as if they were sleepworking. It's time to wake up and do it right-and this book is going to be their alarm clock."
- Jerry Weinberg, author of numerous books on productivity enhancement "In today's complex, fast-paced software development environment, collaboration-the intense peer-to-peer conversations that result in products, decisions, and knowledge sharing-is absolutely essential to success. But all too often, attempts to collaborate degenerate into agonizing meetings or ineffectual bull sessions.…
I've been in the software engineering profession for over 40 years, working at companies as diverse as Bank Leumi, Jet Propulsion Laboratory, Graftek (a CAD startup), Silicon Graphics, Boeing, and Microsoft. As an architect, lead, manager, director, writer, and now career coach, I've been obsessed with finding practical ways to make my work easier, my staff and clients more productive, and our products more delightful. These five books (along with my book and blog) provide proven, time-tested techniques. Each is written clearly with real-life examples, so it is easy to reap the benefits. Smile as you learn to avoid the missteps made by those who coded before you.
Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.
As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.
Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.
Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.
Shipping great software can be done, insists McCarthy, and charts, in five sections, the progress from initial design to successful product. McCarthy is a software industry veteran and the director of the Microsoft Visual C++ development group.
I’ve been a professional software engineer and maintaining open-source software for 16 years. My work on open source has been heavily informed by industry best practises and my work on proprietary software has been heavily informed by open source best practises. Without these books, I’d be a worse engineer on many dimensions. Some of them may feel antiquated but all are still full of relevant wisdom for every open-source (and proprietary) software engineer today.
I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.
The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.
An inside look at modern open source software development and its influence on our online social world.
Open source software, in which developers publish code that anyone can use, has long served as a bellwether for other online behavior. In the late 1990s, it provided an optimistic model for public collaboration, but in the last 20 years it’s shifted to solo operators who write and publish code that's consumed by millions.
In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet…
Markus Gärtner works as Organizational Design Consultant, Certified Scrum Trainer, and Agile Coach for it-agile GmbH, Hamburg, Germany. Markus, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013 and contributes to the Softwerkskammer, the German Software Craft movement. Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craft, and software testing, foremost in an Agile context.
“Good agile testing is good context-driven testing applied in an agile context.”
I recall reading through the authors’ lessons on software testing at about the same time I dived into more agile topics. Lessons Learned in Software Testing helped me keep the connection towards more traditional contexts – more so since I was still working in a more traditional context.
With their more than 100 lessons some of them applied to me, others did not. I am sure, other readers will find the same in their context.
Most companies developing software employ something they call "Agile." But there's widespread misunderstanding of what Agile is and how to use it. If you want to improve your software development team's agility, this comprehensive guidebook's clear, concrete, and detailed guidance explains what to do and why, and when to make trade-offs.
In this thorough update of the classic Agile how-to guide, James Shore provides no-nonsense advice on Agile adoption, planning, development, delivery, and management taken from over two decades of Agile experience. He brings the latest ideas from Extreme Programming, Scrum, Lean, DevOps, and more into a cohesive whole. Learn…
Being able to understand and change reality through our knowledge and skill is literal magic. We’re building systems with so many exciting and unexpected properties that can be exploited and repurposed for both good and evil. I want to keep some of that magic and help people engineer – build great systems that make people’s lives better. I’ve been securing (and breaking) systems, from operating rooms to spaceships, from banks to self-driving cars for over 25 years. The biggest lesson I’ve learned is that if security is not infused from the start, we’re forced to rely on what ought to be our last lines of defense. This list helps you infuse security into your systems.
Loren’s been contributing to security for over 40 years, and this book captures his hard-won wisdom in a way that’s both humble and accessible. It scales from principles and design approaches to in-depth explanations of exactly how things go wrong and how to avoid those problems. (Also, I was honored to write the foreword.)
Designing Secure Software consolidates Loren Kohnfelder's more than twenty years of experience into a concise, elegant guide to improving the security of technology products. Written for a wide range of software professionals, it emphasizes building security into software design early and involving the entire team in the process. The book begins with a discussion of core concepts. The second part, perhaps this book's most important contribution, covers the process of designing and reviewing a software design with security considerations in mind. The final section details the most common coding flaws that create vulnerabilities, making copious use of code snippets written…
Computers have fascinated me since my childhood, having fond memories of my dad's ZX81, but even so I played around I was never truly captured by the programming until I recognized it as a way of writing rather than raw engineering. Through my studies of media sciences I found my fascination with how language can shape perception, and through my work in developer advocacy, I found how communities are shaped as well. Now I am fascinated with how different programming languages can shape thinking, having had the opportunity to solve problems at large companies in nonmainstream languages.
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.
I love to expand my knowledge and learn not just about new technologies, but how things work. I find it fascinating to dig deep into computer programming, technology concepts, and really geek out on things. That’s why I love software development or programming books that aren’t just about some technology and how to do something, but rather books that really make you think and teach you not just programming skills but critical thinking about problem-solving skills. As a software developer for over 15 years and a person who teaches software developers, I have learned that if someone isn’t entertained, they aren’t learning. That’s why I put together a list of fun, entertaining and useful books.
I love writing good clean code. There is something refreshing about writing or reading code that reads more like a book than some obscure instructions to a machine. This book goes into the details of how to write “clean code” and what makes it clean.
I felt like I learned so much about writing good code from reading this book about things that you are never really taught in school or on the job as a software developer.
I found so much of the book so interesting because I could use what I was learning right away to become a better programmer.
If you want to become a better programmer and are looking for a book that will entertain you and be fun along the way, I highly recommend Clean Code.
Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code "on the fly" into a book that will instill within you the values of a software craftsman and make you a…
I’m puzzled by how people and technology evolve—as humankind we created all of these wonders to make our life easier. At the same time, I feel that we are more focus on the technology and processes, rather than people. It drew me to the topic of sociotechnical systems, which fascinates me. I’ve formal education in IT, and everything is binary; however, during my career I was drawn to the intersection of technology and people. My mission in life is to support a new generation of leaders that want to create an organisational environment that puts people in the center!
I love pattern languages. And Team Topologies brings patterns for team types and their interactions. Most importantly, they address fundamental problems of the software industry: how teams organise for fast flow, and how teams cope with cognitive load. The book steams from the author's experience in the DevOps community, and it is widely used across the world. Last but not least, Team Topologies give us a language that support organisation evolution.
Companion book Remote Team Interactions Workbook now available!
Effective software teams are essential for any organization to deliver value continuously and sustainably. But how do you build the best team organization for your specific goals, culture, and needs?
Team Topologies is a practical, step-by-step, adaptive model for organizational design and team interaction based on four fundamental team types and three team interaction patterns. It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity.
In Team Topologies, IT consultants Matthew Skelton and Manuel…
Markus Gärtner works as Organizational Design Consultant, Certified Scrum Trainer, and Agile Coach for it-agile GmbH, Hamburg, Germany. Markus, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013 and contributes to the Softwerkskammer, the German Software Craft movement. Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craft, and software testing, foremost in an Agile context.
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.
In this first volume of the Quality Software Management series, Gerald M. Weinberg tackles the first requirement for developing quality software: learning to think correctly -- about problems, solutions, and quality itself.
Guidelines on management are introduced to stimulate the kind of thinking needed.
