Engineering activities vs. management activities

Mar 30, 2009 | George Fairbanks

This is a letter to my friend Larry
, who is an expert on
software processes and Agile in particular.


Here’s something I’d like your opinion on, and it might become another
blog post for you. I believe we should try to understand engineering
activities separately from management activities. It’s tough to
disentangle them, but regardless of management process you’ll need to
decide what the system should do, assign responsibilities to parts,
and think about (analyze) if indeed the thing you designed/coded will
do what you were asked functionally, and if it will have acceptable
qualities (performance, modifiability, etc.)

I also believe that success depends on aligning the management and
engineering activities. XP and other agile practices are actually a
nice merging of the two. Engineers on space systems may be forced
into waterfall processes (you can only launch a rocket once) and XP
developers may use iterative processes (you can relaunch the website
each week), but both have the same engineering vocabulary —
processes, modules, analyses, tests, etc. My goal with the
architecture book is to help popularize the software architecture
ideas (mostly the CMU/SEI versions of those
) and help
them become de facto standards across all engineers/developers. For
example, Szyperski’s definition of a

is pretty different from the CMU/SEI definition, and his book is not
so old. My book is actively trying to avoid promoting a particular
management process but instead showing that the core engineering ideas
and activities are compatible with a variety of management processes
(agile in particular), but that doesn’t make the book title “Agile
Software Architecture”.

I hate to think of a situation where two trained engineers are at a
whiteboard trying to solve a problem and they do not have the right
abstractions / models to think about and solve their problems. Sure,
they’re bright, so they figure something out ad hoc from first
principles and some fuzzy intuition about chunking large bits of
software. But I’d like them to have a standardized, shared vocabulary
of parts (components, connectors, protocols, properties, etc.) that
are effective for understanding the problems they face. (That’s the
“abstractions” part I discuss in the book’s introduction).
And over time we’d be more effective at sharing our solutions (which
is the “knowledge” part from the intro) the way design patterns were a
success. Right now, most folks have a hard time seeing that the
styles used in operating systems are effective there, and the styles
used in IT systems are effective there, but a client-server OS or a
CSP billing system is probably a bad match. Another example of this
is folks arguing that “your language is stupid”, because it’s not a
good match for problems from a different domain (e.g., Java is
probably not the best choice for OS device drivers and ditto for C and
billing systems).

I’d be happy to hear your thoughts on any of this, but in particular
on these questions:

  1. Do you agree that we should strive to separate management processes from engineering activities?
  2. Do you think that components, connectors, etc. are effective abstractions?
  3. Do you believe the majority of developers understand these abstractions?




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