Essential Software Architecture
Ian Gorton
Springer, 2006; 284 pp.; $59.95; ISBN 3540287132
Like most books on software architecture, Ian Gorton's Essential Software Architecture starts by surveying the many different definitions of the term, and describing what an architect actually does. He then introduces a small case study, which is used as a running example through the next few chapters, and then talks about the qualities architects strive for—performance, scalability, modifiability, security, availability, integration.
With that foundation in place, Gorton moves on to a 40-page guide to middleware, 20 pages on process, and 10 pages (more or less) on how to document an architecture. These chapters (particularly the one on middleware) are a readable mix of description and advice. When talking about message brokers, for example, Gorton outlines the kinds of problems they're meant to solve, and the problems they're likely to introduce.
The rest of the book continues in this refreshingly practical vein. He revisits his case study, then moves on to software product lines, aspect-oriented programming (I'm still skeptical, despite his even-handed treatment), model-driven development and service-oriented architecture, the semantic web, and agent-based systems. The last few chapters are coauthored with others, and while the language is sometimes uneven, the content remains rock-solid throughout. All in all, Essential Software Architecture is head and shoulders above other books on the subject that I've read.
Managing Iterative Software Development Projects
Kurt Bittner and Ian Spence
Addison-Wesley, 2006; 672 pp.; $49.99; ISBN 032126889X
Where Gorton looks at architecture, Kurt Bittner and Ian Spence's Managing Iterative Software Development Projects looks at process. In a way, this book is a tacit acknowledgment that agile programming's advocates have been winning the "ceremony versus speed" argument. Bittner and Spence's hearts are still with the former; they stress up-front analysis and planning far more than the XP crowd. However, they put more stress on the need for short iterations and incremental delivery than books from this side of the fence used to. The result is an even-handed approach to managing large software projects.
Bittner and Spence start with four chapters on basic principles. Unlike most such discussions, theirs contains lots of implementable advice, from avoiding feature creep and increasing morale to an explanation of why time boxing works better than scope boxing. This section of the book also introduces their four-part division of iterations into inception, elaboration, construction, and transition phases, a distinction that is one of the most important differences between their methodology and "pure" agile alternatives.
Part II of the book is titled "Planning and Managing an Iterative Project", and that's exactly what it covers. They almost lost me with the first section, which discusses management layers and responsibilities—deeply nested org charts are one of the reasons I no longer work for a Fortune 500 company—but they got me back when they started describing how to balance risks across iterations, assembling a plan, and different ways to scale projects up. None of its 672 pages is particularly light reading, but if you prefer predictability to adventure, this is a good rulebook for your next project.
Agility and Discipline Made Easy: Practices from OpenUP and RUP
Per Kroll and Bruce MacIsaac
Addison-Wesley, 2006; 448 pp.; $44.99; ISBN 0321321308
Like Managing Iterative Software Development Projects, Per Kroll and Bruce MacIsaac's Agility and Discipline Made Easy: Practices from OpenUP and RUP is a tacit acknowledgment that the agilest have been setting the pace for the last few years. Most of what's here has been part of the Rational Unified Process (RUP) and its kin for years; the difference is mostly the presentation, which basically says, "Agility's great, but you need to have discipline too."
In practice, there's more emphasis on the latter than the former. In fact, I'm not sure that I'd have known this book was about agile development if the word hadn't been in the title. What it is about is 20 "best practices," ranging from "test your code" to "model key perspectives." Each one is presented in a standard form: What's the problem the practice seeks to solve, how do you apply it, at what levels can it be adopted, and what other practices are related to it.
So, why would I choose Bittner and Spence, rather than Kroll and MacIsaac? The main reason is that the former is explicitly prescriptive; that is, it says "do this, then do that," rather than assuming you have a process and want to tune it. I also think that Bittner and Spence's book is more approachable: There are places where I think Kroll and MacIsaac assume more familiarity with big projects (and their problems) than most programmers in their early twenties are likely to have.
