Hierarchy

Recently, I see the concept hierarchy everywhere. I am attending a 3D modeling class, which includes a life drawing class; and at work I am coding an editor for a web application.

In life drawing, Andrew, one of my instructors, says "Go for the large shape first". I think it's easy to imagine that the same advice applies in 3D modeling. After all, both drawing and modeling are about defining shapes.

In programming, it is more difficult to see how Andrew's advice applies. Perhaps it helps to put programming activity in the context of a development project. A project has goals and time limit. Thus, it is sensible to go for the large items first. "Large" in this case I interpret as "essential" or "must have". Then, I progressively go for smaller and smaller items to refine the system's behavior as close to the ideal behavior as possible. I interpret "smaller items" as "non-essential goals" or "nice-to-have items" and "non-essential bug fixing".

I was uncomfortable with "non-essential bug fixing" at first because, as item#5 in the Joel Test suggests, fixing bugs should have higher priority than writing new code. However, in the tight deadlines I was in, it simply felt right that non-essential bugs should wait. Re-reading what Joel wrote, I think what's important is not a rigid "fix bugs first then write new codes" rule; but finding a compromise between implementing new items and fixing bugs in items already implemented.

Anyway, I thought it's interesting to see a parallel between drawing and programming process. Perhaps I see it only now because the life drawing classes forces me to draw in a very limited time (3-minute poses, 1-minute hands, 10-minute faces, etc).