> On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote: >> appropriately, this being a plan 9 list and all, i find code >> written from the bottom up easier to read. > > Depending on the task (on the aim of the software), one happens to split > from top to bottom, and to review and amend from bottom to top. > There is a navigation between the two. > > Bottom to top is more easier because you are building more complicate > stuff from basic stuff.
Some time back, I was trying to understand how to teach the reality of composing software. (Yes, I do think of it as a creative activity very similar to composing music.) The top-down and bottom-up ideas abound and make sense, but they never seemed to capture the reality. Then one day, after introspecting on the way I write code, I realized it's not one or the other; it's outside-in. I don't know what little tools I need to build until I have some sense of the big picture, but I can't really establish the exact boundaries between major elements until I've worked out the cleanest way to build the lower-level bits. So I iterative work back and forth between big picture and building blocks until they meet in the middle. As an aside, that's also when I realized what had always bugged me about the classic approach to team programming. The interfaces between major parts really comes last, but in assigning work to team members, you have to force it to come first. And of course, from that perpsective, it makes perfect sense why the best examples of programming are ones where the first versions are created by only 1 or 2 people and why the monstrosities created by large teams of "professional software engineers" are so often massive collections of mechanisms that don't work well together. BLS
