TITLE: It's Blueprints All The Way Down AUTHOR: Eugene Wallingford DATE: October 24, 2014 3:05 PM DESC: ----- BODY: Many people in and out of the software world think of design and programming as separate activities, which is a natural result of analogies that compare software development to engineering disciplines. I've never been fond of separating these tasks in my mind. When I build software with other people, there is too much fluidity between designing software and writing code to make separate roles productive. In The Myth of the Builder, Soroush Khanlou objects to the analogy for a different reason: designers and programmers are really doing the same sort of thing, only at different levels of detail:
... We know that the designer is not doing the building; if programmer is also not doing the building, how is software turning from idea into reality?
What is happening is that the designer presents the software as very high-level blueprints to the programmer. The programmer then takes those and creates a lower-level set of blueprints for the compiler.
Thinking in terms of blueprints at a higher or lower level helps make sense of how it feels to be: We can think of design and programming as different tasks, but not really as different kinds of task. Khanlou goes a step farther:
(Incidentally, the compiler is producing an even lower-level blueprint, called the Intermediate Representation, which is translated in to a final set of blueprints, the specific instructions for different CPUs. It's blueprints all the way down.)
That's a catchy phrase, with a nod to other parts of computing culture. (I first saw the phrase it's turtles all the way down in Gödel, Escher, Bach, though I think its use in computing goes back farther.) Fortunately for software developers and compiler writers, we eventually hit the bottom turtle. When we write most programs, we don't have to worry about that, though. Khanlou's blog ends with a useful reminder, echoing "Structure and Interpretation of Computer Programs":
It's not valuable to think of software as a bridge; it's too weird for that.
Analogies from software development to various engineering disciplines can take us only so far. Software is different. -----