Outside In Programming

Everyone's heard of BottomUpProgramming and TopDownProgramming, but now I find myself doing what could be called OutsideInProgramming: starting with a very high level description in well-formed pseudo code, and then starting to build the low level pieces that I need, and incrementally working on both until they meet. It seems to work pretty well!

Does anyone else HaveThisPattern?

Outside-in sounds a little bit like what I described in SoftwarePuzzleAnalogy. -- CurtisBartley

I've seen people HaveThisPattern a numbers of times by various names. (None of which I can remember right off the top of my head! ;-) ...usually described as doing both top-down and bottom-up at the same time - like MeetInTheMiddle?. -- JeffGrigg

I believe everyone who succeeds is doing something pretty much like this. It's just too risky to only take a single perspective. The same pattern also holds for planning. You need a top-down view to bound the overall effort; bottom up estimates to add reality. Then they have to meet somewhere in the middle, or you don't have a plan.

But I'm curious as to what makes one approach "outside" and another "inside". Is abstract outside and concrete inside? If so, why? --WaldenMathews

I just wanted to contribute because I recently noticed this in one of my projects, where I used CopyAndPasteProgramming to do the top-down (concrete??) and then fully ObjectOrientedProgramming.

Ttwo possible solutions to the above follow:

visibility:

   outside -> abstract/soft
   inside  -> concrete/hard

eggshell:

  outside -> concrete
  inside  -> abstract

I first thought of the visibility solution because when you're closer to the implementation, there is less guesswork (ambiguity).

Then I thought of the eggshell solution; client code sees the outside as concrete, but is interestingly further from the implementation.

-- etoffi

Surely we all do outside-in all the time. You take the big view model and decompose it into sub-models, breaking the problem into digestible chunks.