Foreword

When I picked up the final draft of this book, at first I was surprised to see that it was missing any mention of Agile software development. Michael and I have been chatting about this book for years now, and I thought I knew what the book was about and why it must be written: software architecture ideas, as traditionally described, have been hard to use in Agile processes, but Michael has figured out how to do just that. So how could “Agile” not be on every page of the book?

Michael is a modern Prometheus, fascinated by technology and determined to tame it for all of humanity. He is a true believer in the benefits of Agile and an expert in software architecture. I know of no one else who was walking the walk as an Agile team leader during the day while mentoring Carnegie Mellon software architecture students at night. I know him best through our involvement in the SATURN software architecture conference, where he has brought ideas and thought leaders from the Agile community to rub elbows with the architecture community. He has been looking for the best of both worlds, a mixture of Agile and architecture that is not oil and water.

There have been other attempts to reconcile the differences, but they have all been limited. Early attempts tried to shoehorn Agile into the implementation phase of a waterfall process. Others implicitly assumed there was still a “corner office architect” making the important decisions. Almost all of them were based in theory rather than reporting on what they had successfully applied and were written by an author in one camp trying to pull in ideas from the other.

This book is a different, better synthesis of Agile and architecture, which is why the word “Agile” is not on every page. It starts with a deep understanding and appreciation for Agile values and describes design techniques that are compatible. Michael has invented or adapted many of the techniques himself, but it thrills me to see that he’s also plucked the best ideas from conferences over the past few years, techniques that are not yet in any other book. If you glance at Part III, “The Architect’s Toolbox,” you will not see “Architect chisels stone tablets for the team.” You will see activities that fit within even week-long iterations, encourage team ownership of the design, and promote the design as a first-class concern of the team. It also has pictures of teams actually applying these techniques.

The same thought leaders who overthrew bureaucratic software processes also cautioned us that Agile was not a disguise for undisciplined cowboy coding. Those bureaucratic pre-Agile processes were, for the most part, disciplined, and you knew which design activities you should do and when. Despite teams self-reporting that they are following Agile processes, my experience is that there is a lot of undisciplined cowboy coding happening today.

Now that this book exists, the question is: what happens next? It is hard to make predictions, especially about the future, but here is what I foresee. We are on the cusp of a transition to a stable state of software development where we have learned to blend agility and discipline. Our processes will use the quick feedback loops popularized by Agile and will guide us to design techniques that drive quality. Unmistakably, they will be software processes, with activities and techniques uniquely appropriate for software development.

We are not there yet, but this book moves us in that direction. Let’s go build the future we want to live in.

Author of Just Enough Software Architecture