In the long distant past before many of you were born, programming was an arcane art involving expressing mathematical algorithms in a code that a piece of electronics could manage. At that time design was very much a matter of having the skill to store intermediate data on a magnetic drum (for example) so that the latency in recovering it was kept as low as possible. The process of programming has changed vastly over the years. However far too many consider programming as little more than that ancient arcane art simplified with high level languages. To too many, a large program is something that takes more than a week to write. In this context, the job of programming is the work of a single individual.
Of course, we have moved on and some actually know that large programs are the work of many individuals but that earlier view still pervades much of the industry. Much current software is built on an ad hoc basis. Everyone thinks that they should be doing the same job. It is rather as if we built houses by getting together a dozen or a hundred workman, giving them a plot of land and building materials and telling them to get on with it. Ancient cathedrals may have been built something like that, but we would not accept that today.
One thing that worries me about software development is that there seems to be a strong assumption that, even when jobs are handed out to different people, you start by cutting code, and if you are any good at it you will move on to something else. You would not expect a building architect to be any good at brick laying, nor that a site manager would necessarily be able to wire a house.
My problem with this book has nothing to do with its contents but more to do with the kind of person who is likely to read it. If you are a good software developer (aka programmer) stick with it. If you are a poor one (or even just someone who finds it boring) and want to explore other paths for a career in software production you might well consider becoming a software architect. If that is the case this would be a good book to read. By the time you have finished it youshould have a firm grasp of what the job entails and a feel for whether it will suit your talents.
Another group of people who will benefit from reading this book are those who are already expected to be responsible for the overall architecture of some software.
Please note that this is not a book about software architecture but about the job of being a software architect. The authors discuss a wide range of topics from training to managing your managers as well as those who will put your designs into practice.
Fundamentally, this book is a guide to how you can become a software architect if you are motivated to do so. The authors use a liberal sprinkling of examples of both good and bad experiences. This makes it a pleasant read as many of us will remember similar experiences. The advantage of this book is that it will help you understand what is good and what is not.
If you want to move away from pure programming towards responsibility for the grand design, and oversight of its implementation this is a book you should read.
