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. ---- See also MiddleOut