I don't find working on whiteboards useful for figuring things
out. What many programming books don't mention is that diagrams
are generally useless for explaining things to oneself, but very
good for explaining things to others.
So, instead of writing diagrams on whiteboard, I pull out
a notepad and scribble out in pseudocode what I think a given
process is supposed to do. Then I can type it in as comments as I
write my code. It gives me a quick way of seeing the big picture
of the code without creating flowcharts.
When you're dealing with nonprogrammers (Muggles? Trivial persons? :) )
it's best to be armed with charts. Nonprogrammers will occasionally panic
at screenfuls of text, but they often feel at home with pictures.
Dive-coding (just immersing yourself into the code without prep work)
feels practical, but sometimes can get you into serious trouble if what
you thought the client wanted and what the client thought they wanted
are different things. But there are other, sometimes far better, charts in this world than
flowcharts. Transition diagrams are good; so are use-case diagrams.
If you are the client, though, by all means dive right in...
And yeah, it's frustrating when a professor makes you diagram,
but it's important to know how to do... since there are more people
out there that think like that professor.
stephen
|