There's a really cool screen saver at http://www.drawinghand.com
. It displays a hand, drawing pictures on your screen. Really nice pictures, Vipers, landscapes, fish. It runs, unfortunately, only on Windows.
It's interesting to watch the hand draw: it is tracing the actual actions of the "artist" who drew the pictures. The approach is generally to outline the objects, or sketch them into the background, fill them with a solid color, then go over them refining and refining. The hand skips around, working a while on one area, then moving to another area.
The picture seems almost to be coming into being, coming out of the fog.
In XP we DoTheSimplestThingThatCouldPossiblyWork
. Sometimes people object to this because you are building a haywire, overly-specific, insufficient chunk of code. The DrawingHand
is a metaphor for why this works.
Today a couple of the C3 developers came to talk with me. They were having trouble, felt buried. They had gone to ask the customer whether they needed to break out a whole bunch of numbers, and they didn't know how to compute the numbers, or how they really should be broken out. They had taken too big a bite.
I suggested that they forget they had asked the question. One of them looked at me and said we had to do it because the customer wanted it. I agreed, and said we shouldn't do it anyway.
To see how to compute the numbers, we needed to build a simple structure of parts, bins, and stations, that got the right answers. They had the tests and needed to get the correct values. Then (and IMO only then) they could worry about how to tag the numbers for classification, probably by building in more bins.
was drawing the Viper on the screen as I spoke with them. I pointed to it and told them to watch. The hand laid in a big blob of a single red, representing the Viper's hood. It was rough around the edges and didn't look much like a car. As we watched, it went back and forth, adding a darker red for shadows, a lighter red for highlights, even some white for reflections. A stupid-looking sketch of the Viper turns almost to photo quality as you watch. You can almost imagine yourself drawing the picture, because you can see what the hand does, and you can see why. "Oh, he's putting in the shadows in the grille."
When you DoTheSimplestThingThatCouldPossiblyWork
, you get the basic shape of the code, and you get it quickly. You learn that it isn't quite where you want it. You move it. Then you refine (refactor) it to make it more and more beautiful. You write additional tests, refine it to do the new capabilities, but you never lose the picture of what you are doing.
Download the DrawingHand
and watch it work. (Consider paying the guy's shareware fee.) Think about how what it can teach you about how to do your work, keeping it simple, making it better all the time. --RonJeffries
Drawing seems likes an interesting tool for examining DoTheSimplestThingThatCouldPossiblyWork
(and the QualityWithoutaName
) in a broader sense.
My drawing is very bad. But it is a lot better than it used to be since I worked through the exercises in DrawingOnTheRightSideOfTheBrain
. The crucial message from the book is that to draw realistically you need only draw what you see
. Unfortunately, most people find this very dificult. They have to learn
to draw what they see. It seems bizzare, but it is so. Apart from a few lucky ones who can't do otherwise, we have to learn to use our perceptions unmodified by what our conciousness would rather we percieved.
It feels like a similar sort of effect occurs in software construction: some developers (and I may be one of them, from time to time) are unwilling to "code what they see" because some part of them seems to think that it knows better. --KeithBraithwaite
Yeah, check out that software; it is really cool!
Why do they call it a screen saver when it keeps the screen busy all the time?
In the 80s, monitors would suffer burn-in if they held the same image for too long. Of course, you could simply turn it off when you walked away from it, but it gave people an excuse to install these "screen savers"... modern displays do not suffer burn-in from any reasonable duration, but people still have the excuse. -- DanielKnapp
I used to run a sketching module as part of a basic architectural drawing course for new architecture students at Nottingham University. Just about the first message to these students was just as noted above 'draw what you see, not what you think is there'. One of the secrets of accurate drawing is looking, and looking a lot. Most early 'artists' have a quick look at the subject then, head down, beaver away 'making the drawing', then finally come up for air again at the end!
What is really needed of course is intensive 'looking' and probably much less 'drawing', maybe 60-70% looking, 30-40% drawing. I don't think we really start seeing until we take the time to properly draw. -- MartinNoutch
What about the left side of the brain & left-handedness? Its interesting that amongst architects & artists there is a much greater proportion of left-handed people than among the general population.
I'd like to see documentation for this. If I *did* see documentation, I would suggest sample bias: Perhaps, say, 25% of all people are more or less ambidextrous, and write with their right hands because that's what they were taught, but artists and architechts need the finest control they can get, so they use their true dominant hand more often. -- DanielKnapp
Neep Nope, the left side of the brain controls the right side of the body, and vice versa. Left-handed people supposedly develop the right side of the brain more, and that is the side that is supposed to be artistic, the left side being analytical.
Here's the interesting thing. Good concert pianists tend to start out center-brained or left-brained, working on the technical aspects as well as style. When the technicalia move into the cerebellum, the right-side takes over as they develop style all the time.
The most important thing about learning to draw is not to use your left brain. Don't analyze the quality of your work, just work. Later, when you're done drawing, you can consider it from any viewpoint you want. Then, you'll have memories of what went wrong, not analysis. You can use these memories the next time you draw, without flexing your left brain. Also, try drawing with your left hand. -JohnDuncan
This software is fabulous.
Having watched the screen now for 15 mins, I discovered so many anologies between painting and Xprogramming. (I like doing both equally, but programming covers a bigger part of my day)
Most important for me is the state of mind I acquire in both cases. It is the same rhythm.
Choose a topic to paint. Hm, think a little while preparing the tools. Choose an appropriate technique. Some quick sketches to prepare myself. Ah, now I have some vision on how it may come out. Ok, the canvas. It's a portrait (my preferred topic) so I have my customer on-site (sorry for that bad joke). I look at her. I look at her without recognizing any detail. Eyes half-closed. The typical "phrases" the general shapes. My hand is moving over the canvas. The charcoal leaves very thin lines. My cell phone rings - I don't even hear it. The general shading blocks marked by hatching, darkest, midtone. I catch myself looking to closely to details - to often and to close to the canvas. I step back. Long arms. Recalibrate myself. I check the big lines. Positive and negative space. The shapes. A little correction.
She asks for a break. NO - NOT AFTER 10 MINUTES! Oh - it's 45? Ok.
She looks at the canvas. Only some shapes on it and no detail at all. "Well - fairly close" she says. Well you know, she's so polite :-) "Are you finished?"
From all the analogies that just cross my mind, this one is interesting: The painting books say that you should work in a way that you could stop at any time with an acceptable result.
(I never tried PairPainting
, though. But I heard that the old masters did a something like that with their "school" members. see also http://industriallogic.com/games/pairdraw.html
Thanks for starting this page (whoever did it). --DierkKoenig
Love the analogy.
see also FlimsyAndBarelyFunctional