Occasionally we stray just a little bit from pure SQL articles and delve into
related areas. If you haven't guessed yet, this is one of those occasions.
On a daily basis I meet with members of our development team to discuss
problems they are working on, problems I need them to work on, or sometimes
problems that I'm working on. It's an informal environment where we go to
whichever office is convenient and talk things through until we get to where we
need to be. Out of each of these discussions we often wind up with a list of
todo items and/or a diagram showing some proposed changes, or maybe the flow of
how a process will work. Not exactly a new process, I'm sure most of you do
Where it gets interesting (to me anyway) is how to have that conversation
effectively. It seems that we almost always look around for something to draw on
so that we can present ideas visually - and then modify those ideas visually as
well. When it is time to draw, we typically have three choices:
- Dry erase board/white board/chalk board
- Flip chart/easel pad
- 8-1/2x11 pad
Leon has a
dry erase board in his office. Not that he consciously decided that it was
better than the other two options, that's just how it wound up. Dry erase is
nice because you change your drawing quickly and still keep it legible, but the
downside is that once you have something complete there is no easy way to move
that to a transportable medium. (Note: I've heard of people taking digital
photos of the board and printing them, not a bad idea I guess, or maybe you're
one of the lucky few who have a board with the built in printing functionality).
A lot of the time the problem is bigger than we can describe on a single board,
so we have to start writing on something else, or start writing a lot smaller in
the left over space. Nine times out of ten when I'm in Leon's office I end up
using a 8-1/2x11 pad because I can't erase what's on the board.
Legal or letter notepads are about as low tech as you can get I guess, but
they do work. If you have just two people working the problem it works pretty
well, but with three or more the size limits it's usability/viewability. Not as
easy to change as dry erase of course, but paper is cheap so you can always redo
it, plus the completed notes are easy to photocopy. Maybe it's just me but I
don't think it works as effectively as either dry erase or a flip chart - I
think because it is is helpful to literally "take a step back" and have
something you can look at from a few feet away.
We almost never use a PC to convey ideas. At most we'll grab a chunk of
source code, or look at a table design. Maybe we just haven't found the right
That leaves the flip chart. It overcomes most of what I consider negatives on
the notepad. Pretty hard to copy of course, and the paper is a lot more
expensive. Not as easy to modify as the dry erase board. For discussions
with developers, at the end of the session they tear the sheets off and tape
them to the walls in their office while they work. Over the past year it has
become my tool of choice for outlining problems/solutions, even for things I'm
working on solo. I'll get up, add some stuff, sit back down, look at the chart
and think on it.
The interesting part about both dry erase and flip chart is they encourage
discussion. When someone walks by or comes in about something else and sees a
new drawing, they often ask questions or have comments that are useful. No one
is going to walk in and see what I have written on my notepad without being
These sessions are really meetings and well run meetings always have minutes.
For us, it's what winds up on the board/paper that we consider the minutes, no
point in investing more time in it. This is a lot more effective than everyone
taking notes while they try to think through the problem at the same time.
A common scenario is for us to revisit the drawing to rethink a problem or
reconsider why we went in a specific direction (a month or more later). Getting
everyone looking at the original drawings seems to get us back into that mental
position quickly - or at least more quickly than just talking about it with no
I'm not here to say that one method is better than the other, just that one
works better for me. What I'm hoping you'll think about is how you convey ideas
and information during these type of brain storming/problem solving sessions. A
lot of what we (developers and DBA's) do is complex stuff. Getting everyone "on
to the same page" isn't easy, but it is a useful metaphor.