Slashdot Mirror
Ask Slashdot: Whiteboard Substitutes For Distributed Teams?
DoofusOfDeath writes I work on a fully distributed software development team with 5-10 people. Normally it's great, but when we're doing heavy design work, we really need to all be standing in front of a whiteboard together. This is expensive and time consuming, because it involves airplanes and hotels. Conference calls, editing shared Google docs, etc. just don't seem to be the same. Have people found any good tools or practices to replace standing in front of a real whiteboard?
Ever tried OpenMeetings (http://openmeetings.apache.org)? It has a whiteboard in it and I have been in group discussions using it, voice and video. Not as good as a face to face but better than having to travel especially when weather makes it difficult. I think Google Hangouts does something like that too but have not tried it.
http://www.rocketboard.it/
No, seriously.
I know I've seen systems that use sensors you mount around the edge of a whiteboard and special markers to track where you are drawing and reproduce it electronically on remote monitors -- it's on a cheap system, but it's cheaper than flying people in airplanes all over the place.
You could also just have the whiteboard person use a graphics tablet, and skip the big arm movements.
Okay, so the submitter asked for "good" solutions, and this may not qualify, but it's what I do: A whiteboard at each location, with a camera pointed at it. I can't draw on your drawing, but I can see what you draw, and you can see what I draw. I've experimented with various web-based shared whiteboards, but they all require drawing on the computer. Even with a tablet (either Wacom-style attached to a laptop/PC or a mobile device) and a pen, a real whiteboard is better.
In my case, generally there are at most three locations in the meeting, and usually only two: My home office and a group of people in a conference room. Having more may make the "real whiteboards" solution less effective.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If you can't express the idea in text and text alone, then you haven't broken it down properly
A picture is worth a thousand words, FOR A REASON.
And you're an idiot.
I don't need to write a manuscript to describe an abstract problem when a couple boxes and some lines will do the same thing. That doesn't mean I've given exact specifications for a problem either.
Anyone who has worked with UML and any real programming language will know that this is true. One UML diagram can result in hundreds of thousands of lines of unnecessary Java code.
Anyone who has worked with UML and thinks you convert that to code doesn't understand code, they've just bought into the UML hype (thats still happening? WTF I thought it died 15 years ago). You seem to think the drawing is the code, and again, you're an idiot. The drawing is a way to describe whats happening in an abstract way so others have a general idea of the concept. It IS NOT the code, its abstract logic.
UML and Java ... you pretty much showed in that little blurb you're not qualified to be part of this discussion. Go back to being a middle manager who doesn't know anything about software design or actually writing code.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
There is no substitute for meeting in person. We've evolved over millions of years to meet with each other in person. Every distributed meeting I've ever attended has had yelling, mumbling, and misheard things caused by technological failures.
If you're sketching out your next year's worth of work, spend the money and get together for it.
If you're just talking about a couple of minor issues, then by all means use a distributed whiteboard.
The problem you're having isn't a whiteboard issue. It's not technology. It's that you're only getting half the message.
You may not be aware of it, but person-to-person communication is extremely high bandwidth. It's so high that we rarely even recognize the component parts of it, and only come up with little more than a mux generalization, like "they're angry" or "they're unsure". Our minds look at someone's stance and posture, at the speed they're blinking, where their eyes are looking, whether or not there's a nearly imperceptible pause when they're about to say certain words, subconscious muscle tics, and so on, and it passes through this great big neural net and some sort of amazing transformation happens and we get discrete knowledge out the other end. What's more, what they're doing is always going to partially be a response to what we're doing; we're providing real time feedback and both of us are adjusting ourselves accordingly. We're so good at it, that about 5 words into an introduction, we can usually tell if someone likes us or not.
On the other hand, a digital whiteboard, even with audio and video, we can't attempt to get this nuance or the feedback response that a person-to-person meeting allows. There's no way to send that much information successfully.
That's why no digital whiteboard will ever beat the real thing. Because these solutions do not allow you to see each varied nuance and react to them, and allow the other parties to do the same in turn. That's why a person-to-person meeting takes 5 minutes to cover what would go 30 minutes in a phone call. Or why video calls always seem to take far more time than you've allocated. That's why all those business types are always doing face to face meetings and ignoring 90% of our technical advances down here in the trenches of engineering, where we're trying not only to solve a problem with technology poorly, but we're not even aware of what the problem actually is.
Let me sum it up for you; there is no technological replacement that comes close to the clarity and efficiency possible - and likely - in a face to face.
If you can't express the idea in text and text alone, then you haven't broken it down properly.
...and at the planning stage, you are still trying to break down the problem. The core concept behind team thinking is that individually, we often fail to analyse the situation completely, and input from others can show holes in our reasoning and things we've failed to properly consider. The whole, hopefully, is greater than the sum of its parts.
I'm coding alone at the moment, and because I have no-one to bounce ideas off, I frequently find myself heading into dead-ends because the problem domain I'm dealing with is very large, and as there's no-one to discuss things with, I need to prototype to find my mistakes. Then I have to go back and rewrite.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'