connect-the-dots, top or bottom

I have never really decided whether I like top-down or bottom-up more. Coding by need (coding by intention and TDD) seem to point at top-down. On the other hand, I have been most productive with ngrease by extracting abstractions from concrete examples, bottom-up.

Maybe the two approaches have more in common than at least I have thought. I think they are both special cases of a more general principle.

Below is a graph that visualizes the idea. At the top (the "x" on the first line) is a high-level specification. The task is to find a low-level implementation (the "x" on the last line) with a path to the specification so that the implementation satisfies the specification:

   . . . x . . . . . .

   . . . . . . . . . .

   . . . . . . . . . .

   . . . . . . . . . .

   . . . . . . . . . .

   . . . . . . . . . .

   . . . . . . x . . .

Sometimes all we have is high-level constraints, and we don't know or care about low-level details. In that case (or rather, during it) top-down might be the natural way to solve the problem.

On the other hand, if we have low-level constraints, like reusable modules we want to use or some technical legacy requirements, it might be feasible to do bottom-up.

The underlying principle is to connect the dots, in whatever order feels most appropriate, be it top-down or bottom-up or some combination of them. Maybe even connect-somewhere-in-between if we happen to have some framework-level constraints, for example.

The second diagram shows the problem after both special cases of this principle have been applied for a while and we have a much smaller subproblem to solve:

   . . . x . . . . . .
         |
   . . . x . . . . . .
          \
   . . . . x . . . . .

   . . . . . . . . . .

   . . . . . x . . . .
              \
   . . . . . . x . . .
               |
   . . . . . . x . . .