The joy of pro bono consulting

Apr 13, 2010 | George Fairbanks

An old friend called me up last week to have lunch and pick my brain
on software architecture. We’ve worked together building software in
the past but he’s been tempted by the dark side and is now the CEO of
a startup company. He needed his engineers to build an architecture
model of their running system ASAP. Fortunately, I had some
materials
ready for him to glance over.

After he and his engineering team read over my book, they drew up a
model of their system and I reviewed it with them. First off, they
fell victim to a few anti-patterns listed in the book (perhaps they
skimmed over those sections):

  • They drew just one diagram (“one diagram to rule them all!”) instead of multiple views, traditionally module, runtime, and allocation views.
  • They had lots of idiosyncratic diagram elements but no legend. I did not know what the different boxes and lines meant.
  • They used arrows on the connectors. (I gave the usual caution, but let them keep these)

We had a nice session looking at the diagram using a projector on the
whiteboard, sketching edits on the projected image while one of the
engineers made edits to the diagram in near-realtime. After a bit of
question and answer between me and them, I learned that their boxes
fell into three traditional IT categories: user interface, business
logic, and persistence. We rejiggered the diagram so that these boxes
fell into columns and then labeled the columns. Aha, it was clear
this was a 3-tier system.

One of the boxes had to span tiers. They had offshored the
development of that piece and its code jumbled the UI and business
logic together. This became clear by the way we drew it, spanning two
columns. We also discussed their future plans to rework that box and
their rationale for outsourcing its development.

This led to the next part of our discussion: rationales and tradeoffs.
They had described the “what” of their design, but not the “why”.
Rationales and tradeoffs are simple and compact to write down but give
great insight into why things were designed just so. For example,
they had outsourced development in order to get to market faster and
the code seems to be reliable enough, but over time it is a hindrance
to modifiability.

There were two joys for me. The first was working with this fun and
motivated team. Sometimes I walk in at the request of a manager and
there is resentment from the team and they are surly and defensive.
Not this time — we had a wonderfully productive session. They were
genuinely happy about how quickly (I was there maybe 90 minutes) we
cleaned up the diagram and made it express the essence of their
engineering.

The second joy was in validating my book. If you’ve ever been part of
a creative effort like writing a book, you know that your baby has
warts but you hope that despite all its problems it is a net
improvement to the world. It was great to have them skim my book,
apply the ideas, and be in good shape with just a few nudges. I bet
if they’d had time to read the book completely it would have been even
faster. So chalk one up for practical software architecture advice.

About

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

Contact

gf-web@georgefairbanks.com
124 W 60th St #37L
New York, NY 10023
+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks