Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Bottom Up Programming Question

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 28 posts

Ask HN: Bottom Up Programming Question

#1

Post by awt »

One thing that I have never quite grasped about the concept of bottom up programming is how to come up with the most basic components of a program without doing some kind of top down analysis. Perhaps I can illustrate my confusion better with an analogy.

Let's say you're designing a duck (in other words, an animal that can fly, has a rounded beak suitable for bottom feeding, webbed feet for swimming, etc). In a Bottom Up approach, you would start with cells. You would need to create skin cells, bone cells, eye cells, nerve cells, etc. In order to even get to this stage, however, you would first have had to have divided the duck up conceptually into different parts in order to know that different cell types are needed. Thus it seems impossible to do bottom up programming with out first doing some top down conceptualization.

So, once again the question, how can bottom up programming work without some level of top down design?

Re: Ask HN: Bottom Up Programming Question

#3

Post by 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.

Re: Ask HN: Bottom Up Programming Question

#4

Post by patio11 »

Duck 1.0: Has a beak, which can open and close, but only eats green bugs. If you attempt to use it on a blue bug it crashes. Unfortunately, no eyes.

Duck 1.2: Eyes.

Duck 1.21: Eyes now see color.

Duck 1.22: Eyes now see colors including black. Apparently, some bugs are black. Damn users and their damn uncolored colored bugs.

Duck 1.5: Realized eyes and mouth both share a lot of code. Refactored as "nerves". Allowed consumption of turquoise bugs -- not exactly sure why they're safe when blue bugs are not, oh well. Added quack just for fun. Spent 2 weeks getting the quack to sound exactly right.

Duck 2.0: Now with feet and wings! Turns out to have feet you really need muscle tissue. Refactored again, stealing code from Mouth. Supported modes of operation include walking, running, and swimming. Option in menu entry for flying but if you push it the duck dies.

Duck 2.1: It glides!

Duck 2.11: So it turns out that to utilize the gliding feature users were driving ducks off of tall cliffs. This resulted in downward acceleration being sufficient at end of glide to overly stress feet muscles, causing critical duck failure. Added in Bones. Damn users and their damn cliffs. As long as I had Bones I implemented them in the Mouth too, can finally eat blue bugs.

Duck 2.12: Some blue bugs are poisonous?! WTF kind of bugs do you have in Australia. Added in Tongue. Borrows heavily from existing Nerve classes. More refactoring.

...

Re: Ask HN: Bottom Up Programming Question

#5

Post by patio11 »

patio11 wrote: post #4

Duck 1.0: Has a beak, which can open and close, but only eats green bugs. If you attempt to use it on a blue bug it crashes. Unfortunately, no eyes. Duck 1.2: Eyes. Duck 1.21: Eyes now see color. Duck 1.22: Eyes now see colors including black. Apparently, some bugs are black. Damn users and their damn uncolored colored bugs. Duck 1.5: Realized eyes and mouth both share a lot of code. Refactored as "nerves". Allowed c…

And if you think that is at all unrealistic, you're talking to the guy who wrote a program to print bingo cards whose 1.0 version, among numerous other faults, could not accommodate any printer but the default one ;)

Re: Ask HN: Bottom Up Programming Question

#7

Post by gruseom »

andreyf wrote: post #3

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 compo…

Another great metaphor I find analogous is "Mozart vs. Beethoven" style programming

Wow, that's really interesting. I find Beethoven to be an incomparably greater composer than Mozart, and I feel the same way about the exploratory approach to making software: it's just obviously better. Whether it is obviously better or just a better fit for me is a fair question. I will say, though, that I don't feel the same way as you about the advocates of the top-down, up-front style. What have they built? What systems did Dijkstra build? As far as I'm concerned the great practitioners are pretty much all lined up on one side. Counterexamples are welcome.

(I should add that I don't mean to belittle Dijkstra's achievements, just that as far as I know they didn't lie in the direction of building working software. Of course that didn't stop him from castigating basically everyone who did do that.)

Re: Ask HN: Bottom Up Programming Question

#10

Post by gruseom »

Your analogy seems to me to go awry here:

you would start with cells - sounds good

you 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.)

Post reply on HN