Programming by Wishful Thinking

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

Coderetreat: Programming by Wishful Thinking

Blog post series

This blog post is part of a series about coderetreat sessions.


This session introduces the concept of top-down approach of Test Driven Development for a new feature.
By following the steps you will be able to understand how to add thin top-down features that you can show very fast to your customers. Many of the features will work, even though you will not have a fully functional system, just because you have used stubs or fakes for the parts of the system that are not yet implemented.

Programming by Wishful Thinking


You want to implement a feature using Test Driven Development starting from the user interface. We call this kind of development top-bottom, as opposed to bottom-up, when you start from the database.
Let’s say your system is brand new, and you need to start from somewhere. Because you want to be Agile, your first feature needs to be a vertical slice from the user interface to the data layer. You want to receive feedback as soon as you can from your stakeholders on the new feature.
How do you do that?
One solution: Programming by wishful thinking.

The first step is to find the scenario you want to focus on. This means that the business is very clear and you can do a vertical slice of the requirements.

Once you know what you need to do, you write an acceptance test. For that you need to implement the top and the bottom layer. This test will fail until you have implemented the last unit test.

You start writing unit tests from the top layer (user interface) to the next layer (maybe a view or a model). If you need any information you create an interface or a function and create a stub. That stub will give you all the information you need. This is where you are doing some wishful thinking. Whatever you need and don’t have, think that you have it and write a stub for it. Working in this way will give you the opportunity to focus on the vertical slice, from the top layer to the bottom. Don’t get distracted implementing anything else, just write a stub.

You continue to write code like that, writing tests on each layer until you reach the bottom layer. When the last test is implemented, the acceptance test should pass. This is when you can show your new scenario to someone for feedback.


You will be able to understand better what top-down Test Driven Development is. Another important outcome is that you can understand one of the ways of doing Evolutionary Design.

You can develop a product with a fast feedback cycle by using this method. Once a feature is finished you can show it to your stakeholders. They will come with improvement feedback that you can act upon.


The top-bottom Test Driven Development approach is very appropriate for web development. You pass through all the layers and write the needed tests, add the needed functionality. Nevertheless top-bottom is not that useful when writing algorithms, there I would recommend you to try a bottom-up approach to Test Driven Development.


During all the steps you are taking incremental design decisions:

  • When writing the acceptance test you design the top and bottom layer
  • With each unit test you design bit of each layer
  • With each stub you design the interaction with future collaborators that are not yet implemented

The design evolves with each step you take. This is why I call this way of working Evolutionary Design.


When working in this way you need to have solid skills of business analysis, software design, TDD, and testing.


I know about his session idea from Corey Haines. Thanks Corey for telling me about this way of working.

During a few of the coderetreats I facilitated I presented this concept as a constraint. The fastest pair was when a tester was pairing with a programmer.

Code Cast

Somewhere in the future there will be a code cast showing this method of writing code.


Feel free to contact me to find more about methods of evolutionary design.


If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

3 thoughts on “Programming by Wishful Thinking

  1. This cuts to the heart of TDD. There’s a similar technique you can do in type-driven development: write out the type signatures of your data types and functions, and add preconditions wherever you can think of them. Preconditions for functions act as guarantees they’ll be called properly, and preconditions for data types guarantee runtime values are valid. The data types and functions don’t need to be implemented immediately; the same ‘wishful thinking’ principle applies. This is great for modelling the system at a logical level without implementing anything.

    Suppose you want to model a rational number: a ratio of two integers, where the denominator must be greater than zero. You can start by making data types:

    value: Int, value > 0
    numerator: Int
    denominator: PositiveInteger

    Now you have the guarantee that the ratio will always be valid. But there’s more: you can add operations:


    add(ratio: Ratio): Ratio
    multiply(factor: Int): Ratio

    And so on. These operations also provide guarantees through their type signatures: only valid ratios can be added, ratios can be multiplied only be integer factors, and both operations must result in valid ratios.

    This is a simple example but the same method can be applied to model a system at any scale: you’re just writing out its logical properties using types and preconditions, before even implementing anything. If you write it in an actual language with, say, ‘null’ as the implementation, the compiler will tell you if all your logical assumptions hold up.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles