A few words from Jack Ganssle...
|
Foreword
The oldest known book
about engineering is the 2000-year-old work De Architectura by Marcus
Vitruvius Pollio. One historian said of Vitruvius and his book, "He
writes in atrocious Latin, but he knows his business." Another
commented, "He has all the marks of one unused to composition, to whom
writing is a painful task."
Does that sound like the last ten technical books you've read?
Engineers
are famous for being very bright but also for lacking basic writing
skills. Yet writing is still our primary means of communication, so we
buy heavy tomes created without the benefit of basic grammar and often
bereft of a coherent structure. Storyline? Character development?
Forget it.
Welcome to a very different kind of technical book.
Lisa Simone's work isn't the usual dreary tome stuffed with arcane
wisdom buried beneath paragraph-length sentences seemingly written by
someone just learning English as a second language. This is certainly
the first embedded book with characters. The first with action, and
with interesting and cool stories.
Bad code that makes a phone burst into flames?
What fun!
This
is a James Patterson-style fast-paced book with dialog as close to
gripping as one can imagine for a computer book. Its uniquely embedded
focus twists together elements of hardware and software just as we
engineers do in our daily design activities. One can't be understood
without the other. Code makes the hardware smoke. That's unheard of
anywhere but in the embedded industry.
Lisa weaves stories
around deep technical issues. She's teaching the way humans have
learned for 10,000 years. Most of us fought off sleep with varying
levels of success in high-school history classes. Who really wants to
memorize the date of the First Defenestration of Prague or the name of
Polk's vice president?
Yet now as adults we eagerly consume
historical fiction (like James Michener) and real history assembled as
a story (consider David McCullough). Cro-Magnon Grog taught his sons to
avoid poisonous berries by telling them of uncles who died; the Old
Testament was passed down orally as a collection of stories rather than
a dreary recitation of facts. Not properly casting an unsigned char
sounds pretty dull, but when captured as a story - the interaction of
people puzzling out a problem in the real-life settings we can all
identify with - we're engaged and we learn the important lessons better.
This
book is more real world than the standard text. Lisa shows how people
are part of the solution and part of the problem. The concept draws on
an oft-neglected axiom of the agile methods: people over process.
Despite
the stories and character development, this is a textbook of a sort.
There's homework. When Lisa asks you to stop and answer a question, do
so! Think. Reflect. Surely Grog asked his sons questions to make them
consider the lessons he'd imparted. We learn best by such interaction.
Readers of Watts Humphrey's brilliant yet ineffably dull A Discipline
for Software Engineering either do the homework and see their skills
skyrocket; or read the book, skip the homework, and get no benefit at
all.
Buried under the lessons, Lisa derives an important
zeitgeist, a design pattern if you will, that should guide us in our
work. It's one of creating readable work products: use cases, comments,
requirement documents, and more. Though we need not emulate her use of
story development in writing a report, we should and must abandon our
traditional use of tortured English. Write interesting documents. Be
lively and engaging. After 2000 years, it's time to leave Pollio's
legacy behind and realize that if our readers are confused, frustrated
or bored by what we produce, we're history.
|
|