Introductions are hard
You may recall writing your first essays in high school and struggling with introductions. There was probably some advice about going from the general and honing in on your specific topic, and ending up with a topic sentence. Over time this got less painful (both for you the writer and whoever had to suffer through your essays), but the introduction to a book is a whole new world of hurt. You’re trying to hook in and interest folks who come with any number of prejudices about your topic, experts and novices, academics and practitioners. Of course here when I say “you” I really mean “me” because that’s what
I’m struggling with for my book intro. What I’ve posted below is the N-th rewrite of the first few paragraphs of the intro. I’m not happy that it starts out with Agile programming, and may paint them too much as the enemy of design, but here it is for your enjoyment. Comments are, as always, gratefully appreciated.
Over the years, software development practices have become so burdened with heavy techniques that a rebel group, known as Agile developers, has sought to pare the development process down to a minimal core. Agile developers emphasize the developer’s skills in crafting the parts of the program they directly manipulate, usually objects and classes, and de-emphasize analysis and design. Although they are careful to point out that Agile techniques only work on a subset of projects, it is clear that there is rising mainstream disdain for analysis and design, which includes software architecture.
When a grizzled coach and a rookie watch the same game, the coach sees more than the rookie not because his eyes are more acute, but because he has built up a set of abstractions in his head that allow him to convert what he perceives as raw phenomena, such as a ball being passed, into a higher level understanding of what is happening, such as the success of an offensive strategy. Software architecture research started after developers had been successfully delivering systems for decades, but its goal is to understand and encode the abstractions that veteran developers can see but the rookies cannot. When that knowledge is successfully transferred, it accelerates the progress of the rookies into veterans.
What a developer sees and understands is different than the software development process he follows. A smaller project team may all work in the same room and occasionally sketch on whiteboards, while a larger project may be distributed and need to publish documents that describe their designs. But both teams need to understand the core software architecture abstractions and be able to make design decisions that reconcile opposing design forces. Both teams will understand that any kind of engineering, including software engineering, requires understanding the risks of failure and how to apply appropriate techniques to mitigate those risks.
Smaller projects may be adequately served by existing abstractions, such as objects and methods, but mid-sized and larger projects will benefit from the use of higher concepts such as components, connectors, and ports. This book describes how to efficiently use software architecture concepts and techniques to address risks faced by your project.
