In common with 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. But that term seems to have a life of its own which 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 backwards. 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. And that’s a story for another day.)
So the core of the approach 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).
And 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. And 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.
(I have some availability in the next few months if you would like to see this in action and learn how to apply it to your code.)
Back in the day I used to say this about test-driven development:
If ever I get a surprise, it means I have a missing test.
That is, if I’m in the GREEN or REFACTOR step of the TDD cycle and my changes make something else break, I need to add a test to document something that I must have missed previously.
I don’t think that now. These days I am much more likely to say something like:
If ever I get a surprise, it means I have accidentally discovered some connascence that I was previously unaware of. I need to eliminate it, weaken it, bring the connascent code closer together, or refactor my names so that it is clearly documented.
I’ve discovered some refactoring that needs to be done, and I wouldn’t necessarily rush to add tests.
This month James Jeffries and I ran a session at Agile Manchester in which we (ie. Jim) live-coded Dave Thomas‘s Back to the Checkout kata. The twist was that during TDD’s “refactor” step we used only connascence to decide what to change.
(I know I’ve done that before, on this blog. But this time Jim and I started with different tests. And we practiced a bit first. So the resulting refactoring steps are quite different than those I wrote about earlier.)
@ruby_gem kindly pointed her laptop at the screen and recorded the session. (The beauty of this setup is that you get to see what Jim types and hear how we explain it, but you don’t have to suffer from seeing either of us.)
The slides we used are on slideshare, and I’ve uploaded the resulting video to youtube for you to view at your leisure. Comments welcome, as always.
Recently I wrote a series of posts in which I attempted to drive a TDD episode purely from the point of view of connascence. But as I now read over the articles again, it strikes me that I made some automatic choices. I explicitly called out my design choices in some places, while elsewhere I silently used experience to choose the next step. So here, I want to take another look at the very first step I took.
Am I over-thinking things with this Checkout TDD example? Or is there a real problem here?
Based on insightful input from Pawel and Ross, it is clear to me (now) that there is CoA between the currentBalance() method and the special offer object(s), because the method doesn’t give those objects any opportunity to make final adjustments to the amount of discount they are prepared to offer.
However, as things stand there is no requirement demanding that. Does that still mean the connascence exists? Or is it a tree falling in the forest, with no tests around to hear it?
I had a very interesting discussion today with Ross about my recent connascence/TDD posts. Neither of us was happy about either of the solutions to the corruption problem with the special offer object. Even with the cloning approach, it still seems that both the Checkout and the MultiBuyDiscount have to collude in avoiding the issue; if either gets it wrong, the tests will probably fail.
After a few minutes, we realised that the root of the problem arises from the MultiBuyDiscount having state, and we began to cast around for alternatives. At some point it dawned on me that the origins of the problem go right back to the first article and the first couple of refactorings I did.
In the previous five articles I have test-driven a classic code kata, using only connascence to guide me during the factoring steps. Here I will summarise the steps I took, and review the final code.