Whiteboard Architecture

Wednesday, March 28, 2012

Laboratory whiteboard, featuring metaheuristicsIt's been my observation that the worst architectural decisions are made when technical people meet by themselves in a room with a whiteboard. I'm not saying the decisions are always bad, or wrong, but the plans and rules that come back to bite you consistently seem to incubate under these conditions.

I first witnessed this early in my career when "the architect" would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture. I'm ashamed to say that I had no idea at the time just how utterly insane the process was that we were involved with.

I'm happy to say I've never seen malpractice on such a grand scale in many, many years. However, from time to time I still find myself in a room full of developers and a whiteboard. It's sometimes hard to keep the conversation grounded and not solve problems that don't exist, or devise rules that offer no practical benefit. For example, a rule about how to divide the solution for a new application into umpteen projects before the first line of code is checked in.

I think there are two strategies to avoid architectural flights of fancy. One strategy is to keep a business person in the room. The business person can help a team focus on the real problem to solve, and avoid trying to solve problems that don't exist. The second strategy is bring up application code, and even do some group programming to flesh out details. If the problem doesn't lend itself to group programming, it might be time to let one or two people go off on a spike and bring back some code to evaluate.

Without something tangible and real in the room, it's easy to succumb to the dark side.


Comments
gravatar David Gildea Thursday, March 29, 2012
Hi,

I like your post but I wouldnt fully agree as I have certainly seen cases where a bunch of technical people get into a room with a whiteboard. At a high level
1 So that everyone fully understands what you are doing and also what you are not doing.
2 Give all people in the team a chance to stand up and give there 2 cents where everyone is listening.
3 Starting group coding I find leads to the strongest coder directing everything with there favourite tool or golden hammer and not taking a step back and viewing the overall application to see what works best where.

I do think you have a point and its about finding the right balance between the 2.
Dave
gravatar Joe Thursday, March 29, 2012
I have to disagree with Dave on one point. Part 2 of his thesis only works if you have a single leader to keep everyone on point. Design sessions I've been a part of that did not have a single strong leader usually end up devolving into the tangents mentioned in the original post.
gravatar Muhammad Hussain Thursday, March 29, 2012
Hi,
I am sorry I do not agree with your point. Because I always use a notebook to solve or make a concrete logic. Although I have access of whiteboard.
Bob Thursday, March 29, 2012
You're giving the whiteboard the blame that ought to fall on the architect.

There's nothing wrong with a room full of developers and a whiteboard . In fact it's the ideal medium for drawing high-level architecture diagrams so that everyone understands the target.

The problem comes when the architecture doesn't fit the problem, and the team doesn't have the power to adapt the architecture.
gravatar Dan Sutton Thursday, March 29, 2012
Whiteboards work brilliantly when there are novices and/or non-programmers in the room.

For example, one method of object oriented design in which any member of staff can participate involves writing a large number of very short sentences to describe what you want the application to do, then taking the nouns from those sentences and writing each one on an index card, and sticking that on a whiteboard. The verbs in the sentences represent your use cases, and some of them (the verb "to be", for example) represent subclassing and so forth. You move the nouns around and draw lines between them (some double-sided tape is really handy at this point) and eventually you end up with a pretty serviceable object model. Of course, the thing here is not to take the result 100% seriously... but it's an entertaining exercise, and as the object model forms itself, the non-programmers feel much more affiliated with the project: in their minds, they've just learned something incredibly profound, and they find themselves leaving with glimmers of understanding.

Of course, then you can really put the cat among the pigeons by suggesting that the same approach could be used with corporate management... or national politics...!
gravatar Mat Bollie Monday, April 2, 2012
You arcticle is just plain wrong. Your not talking about whiteboarding, you're talking about management failures on projects.
gravatar scott Monday, April 2, 2012
@Mat - In a command and control organization ... perhaps, perhaps not.
gravatar Carson Tuesday, April 3, 2012
Hey how did you get a photo of my whiteboard to illustrate this blog post? Industrial espionage!!

:-D
gravatar Mat Tuesday, April 3, 2012
"@Mat - In a command and control organization ... perhaps, perhaps not."

Was that a sly dig at something?

Every project needs management; even if it is a only a developer managing himself. Totally amazed that developers aren't given some management basics at Uni, because they'll need those skills as much as anything else. :p
gravatar scott Tuesday, April 3, 2012
@Mat - no, not a dig, honest.
S P Thursday, April 26, 2012
The main problem I had with most of the design discussions that I was part of, was that most of the people in the room (including me) would not be 'prepared' for the discussion. It would really help if everyone did their homework (and were provided with all the info to do that homework) before coming to the meeting, rather than hearing the problem for the first time and understanding it and then analyzing it, etc etc, right then and there.

Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!