Like many other programmers, I have been using the term “outside-in” development for a long time. I suspect I first encountered it in the writings of Steve Freeman and Nat Pryce, and I’m sure they got it from someone else. Unfortunately, the term can be confusing (I find its Wikipedia page baffling), and I find that it doesn’t capture the whole essence of the way I write software these days. I have also tried using the term “programming by intention,” as advocated by Ron Jeffries. However, that term seems to have a life of its own that is only tangentially related to the way Ron uses it.
The approach I want to describe is this: I begin with the code that wants to consume the outputs of whatever I’m about to develop, and then I work backward. First, I hard-code those outputs by creating new code “close to” the consumer so that I can see that they work. Then, I push the hard-coded values further down one layer at a time until I’m done. (I am also likely to write automated tests, but only at the highest convenient levels rather than having tests for every new level of decomposition I discover. That’s a story for another day.)
The core of the approach that I use is that I begin with a consumer and I write some code to make them happy. Then I treat that new code as the consumer for a new layer of code, and so on. Each layer is written “intentionally”, and does just enough to satisfy the layer above it (and thus all of the layers above that).
Where some layer is providing hard-coded values to its consumer, I think of that code as making simplifying assumptions. It does the job it was asked to do, but only serves a tiny fraction of its audience’s ultimate needs. These hard-coded values aren’t fakes or prototypes; they are a way of creating thin vertical slices quickly. Once I know they are correct, my next coding episode will be to bust one or more of the assumptions by driving the code down to the next layer of detail.
I want to call this consumer-driven development. It’s nothing new, but it seems to surprise teams whenever I demonstrate it.