Introductions are hard

Jan 13, 2009 | George Fairbanks

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

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.


George Fairbanks is a software developer, designer, and architect living in New York city

+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks