Carpentry is an exacting craft, and people can spend their entire lives learning how to do it well.
But carpentry is not architecture: if we step back from pitch boards and miter joints, buildings as a
whole must be designed, and doing that is as much an art as it is a craft or science.
Programming is also an exacting craft, and people can spend their entire lives learning how to do it
well. But programming is not software architecture. Many programmers spend years thinking
about (or wrestling with) larger design issues: Should this application be extensible? If so, should
that be done by providing a scripting interface, through some sort of plugin mechanism, or in
some other way entirely? What should be done by the client, what should be left to the server,
and is "client-server" even a useful way to think about this application? These are not
programming questions, any more than where to put the stairs is a question of carpentry.
Building architecture and software architecture have a lot in common, but there is one crucial
difference. While architects study thousands of buildings in their training and during their careers,
most software developers only ever get to know a handful of large programs well. And more often
than not, those are programs they wrote themselves. They never get to see the great programs
of history, or read critiques of those programs' design written by experienced practitioners. As a
result, they repeat one another's mistakes rather than building on one another's successes.
This book is our attempt to change that. Each chapter describes the architecture of an open
source application: how it is structured, how its parts interact, why it's built that way, and what
lessons have been learned that can be applied to other big design problems. The descriptions are
written by the people who know the software best, people with years or decades of experience
designing and re-designing complex applications. The applications themselves range in scale from
simple drawing programs and web-based spreadsheets to compiler toolkits and multi-million line
visualization packages. Some are only a few years old, while others are approaching their thirtieth
anniversary. What they have in common is that their creators have thought long and hard about
their design, and are willing to share those thoughts with you. We hope you enjoy what they have