Some visual notes from a subject I’ve been pondering today. I was listening to the Stanford Programming Methodology lectures on my way in and the professor was very strongly advocating the idea that code ought to be written from the “top down” meaning that you start in the problem space defining abstractions which will be easily understood by humans before getting down into the details of the solution with code that the computer will know how to execute. This struck me as odd because I just finished going through the MIT 600 course where another professor taught fairly the opposite approach where he started with the lowest level abstraction in a system so he would be writing code that he could unit test from the start. The later approach is the only one I have ever practically built anything with (although, I have often attempted to start from the other end, but usually that produces legacy code that doesn’t really make sense once I make my way down to the guts of my app) and I’ve found that other devs who I highly respect work from the “bottom up” and only discover the proper abstractions of their system once they have something that is working, at which point they produce those through a process of refactoring and optimization (optimizing for redundancy rather than for performance, that is).
This seems similar to a question I had when I was really trying to push my drawing abilities a while back – do I start by visualizing an image entirely in my head before I put my pencil to the paper, or do I start with a vague notion of what I want to depict and start moving my pencil around immediately and work out the details as they emerge before my eyes? The impulse I had was to think that I should be able to fully imagine it and produce it – as though in 2 steps, but the reality was that I had to work it out on the paper and learn through the feedback loop of accidental discovery in sketching. Or thinking of animation (which is a bit more parallel to the interactive nature of software than static illustration) the standard approach is to mark out keyframes, leaving the tweening to a lower level production effort – as opposed to working “straight ahead” (meaning to draw frame by frame without thinking of keys). Perhaps that is mixing the metaphor, since it leads to thinking about waterfall versus agile processes — which I think is generally more about roles and how you incorporate design (as in “what are we building”) than it is about how you take on the task of system architecture for a given problem. Or perhaps it is all related.
Anyway, that’s sort of random and tangential, but I suppose so is the creative process.