Bottom Up Programming Question
gruseom: Your analogy seems to me to go awry here:you would start with cells - sounds goodyou would first have had to have divided the duck up conceptually into different parts in order to know that different cell types are needed - does not follow.I noticed that your premise assumes a requirements analysis that already nails down what the program is supposed to do. While that way of thinking is common in the corporate world (where, I note in passing, effective software development is not common - coincidence?), it doesn't fit well with the style of programming you're asking about. If you've read PG's piece on the subject (http://www.paulgraham.com/progbot.html) you may recall that there's one passage in it that he emphasized. It begins:It's worth emphasizing that bottom-up design doesn't mean just writing the same program in a different order. When you work bottom-up, you usually end up with a different program.The program changes as it evolves and your understanding of what the program is changes as it evolves [~]. All sorts of interesting feedback loops result.When I work this way, I listen to what the code is telling me. That is, I start with something primitive (your "cells" in the analogy) and sense where it's leading. Perhaps it's akin to riding a horse where there's a balance between what you want to do and what the horse wants to do; or to creating a piece of art where the creative process incorporates feedback from the medium itself and from the work as it's emerging.That doesn't mean it's all spontaneous, with no guiding factor. If that were true, no system would emerge - you'd just keep going around in circles and finding yourself back at the primitive level. But the guiding factor is not at all like "dividing the duck up conceptually into different parts". It is more like having a felt vision of what a duck would be like. You have that vision and you keep referring to it as you go along. But the vision itself clarifies, and sometimes changes, in response to what happens in the code. You discover what the system is as you make it.Learning to listen to what the code is telling you is one of the most interesting things you can do as a programmer.([~] PG's piece doesn't say that your concept of what the program is changes, only that the constructs it's composed of will be different. I think the two are related though.)