Bottom Up Programming Question
andreyf: It isn't a question of "only top-down" or "only bottom-up". Of course, some thinking will have to go in from both directions. This is why, personally, I think the directed-tree metaphors don't really work.A much better way of thinking about "bottom-up design" is exploratory programming - where one decides what to write by writing it [1]. This means you start by discovering and solving sub-problems, by creating components which work in their own right, documenting and unit testing them (if you're working in an environment that needs it), and moving on to solving bigger problems using said components.On the other hand is the "architecture approach" - where you measure twice and cut once. By "measure", I mean decide what all of your components will be, write out UML diagrams for them, figure out your types, your interfaces, and the contracts between them, write unit tests, and only then begin to write run-time code.There are much more experience programmers than me who advocate both ways, so it's hard for me to make a call [2].Another great metaphor I find analogous is "Mozart vs. Beethoven" style programming: http://stackoverflow.com/questions/292682/understanding-dijk...I like this one because suggests that you can make "great" programs either way. I use the quotes, because obviously, music is a matter of taste, as is the quality of software we develop. This is important to remember - for some people, Windows is the perfect OS out there (for example, those concerned with Microsoft's profits over the OS's usability).1. http://arclanguage.org/2. Although the ones who advocate exploratory design seem more well-rouded: Alan Kay, Paul Graham, and the 37signals guys come to mind. Since I want to be well-rounded and not a specialist, I try to follow in their example. Obviously, this is a subjective judgment.