Wishful Programming (or: Programming by Wishful Thinking) is something I heard about for the first time a couple of years ago. It is a very powerful programming practice, but I found many programmers are unaware of it.

Wishful thinking is a general technique to help you think in abstractions. As far as I know it was first mentioned in the context of programming in Structure and Interpretation of Computer Programs. This brilliant book suggests to defer the decision about how to represent your data by imagining you have any function you wish you had in order to solve your problem in the simplest way possible.

In other words, you write some code that uses a component, before you implement the component. This helps to discover what functions and data you need, and following this discovery will lead you to more simple and useful APIs.

I find that this technique is especially valuable with an outside-in approach for implementing a feature. To start with, it helps writing acceptance tests in terms of business functions. Details about how the system implements these functions are hidden from the context of the acceptance tests and implemented in a fixture.

Once the acceptance test reads pretty much like the high-level steps you would take to execute the feature and fails with a decent error message it’s time to implement the feature. I drive out the design using TDD, starting at the point where the acceptance test fixture integrates with the production code. This allows me to design any collaborators right from the tests in the form I want them to collaborate, without worrying about creating them first.

In other words, I write acceptance tests using a fixture I wish I had, and then implement the feature using collaborators I wish I had.

That is wishful programming. I’ve seen how this helped my code to evolve and be more structured in terms of the solution domain, rather than a sequence of technical steps. I hope being aware of this technique will help you in the same way.