Whiteboard Architecture

It'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.