Testdriven development, TDD, is a well-known technique to be able to focus on the tiny next step of specific functionality to implement. My experience from watching a number of coders in our Dojo’s, and from my own work, is that even though focusing on the test is the idea, it is easy to get side-tracked. All the little details that need to be set up before arriving at the assert statement at the end of the test are distracting. Instead of focusing on the feature the coder starts thinking about which variables are needed, their names, are there any constant values, which handy functions do we need to write. This sequential mode of coding is particularly obvious in more inexperienced programmers and splits the focus. Trying to keep many details in your head at the same time as trying to maintain the direction of the test is hard.
I’m a mediocre programmer and I have a hard time keeping all the details in my head. I need help to focus on what is to be achieved. TDD has been a tremendous help and is my safety net. But to get one step further I have started to use a technique, or rather coding style, that starts with writing the assert-statement first. Yes, just the assert. This helps me think about what the test should actually test before I think about how to set up the test. Let’s call that “Assert-first coding”.
In the same way as for the assert statement in the test, you can start with the end result in the production code. E.g. the return statement in a function is the required goal. Once the return statement is in place we can think about, and implement, what is required to get statement to compile. Step by step we can work our way backwards until we have the complete function. Let’s call that “Backwards directed coding”.
Espescially in typed languages and with modern IDE:s like Eclipse, it is possible the use the Code Completion and Quick Fix features to quickly and easily fill in the gaps and create the pre-requisites to get the assert or return statement to a runnable state. Let’s call that “Completion assisted coding”.
If you combine these techniques you get a style that could be called “Assert-first, Backwards directed Completion assisted Coding”, ABC;-) Thanks, Joakim Holm for the name. (I initially called it “ACBC”.)
I’ll get back with some screen captures to show what I mean.
Nice, Thomas! This is a technique that I enjoy. Sometimes, though, if the path is too long, I find it difficult to move strictly backwards. In these cases I often try both forwards and backwards at the same time. Attacking from two fronts, so to speak. Have you tried this?
One comment: Why not simply call it ABC coding? Assert-first, Backwards-directed, Completion-assisted. This is simpler. As simple as ABC, in fact. 🙂
Thanks, Jocke! I like “ABC”, so I’ll update to use that name instead. Maybe you can update the title to my proposed Lightning Talk at “Agila Sverige” 😉
Attacking from two fronts is, in a way, what I get when I forget to use ABC. This is not always a bad thing. Probably, there is some benefit from structured, and conscious, alternating like you suggest. And even when you go forward you need to remember to forget the little details (declaring variables, etc.) in order to keep your focus. And let the IDE do the job it does best, completion and quick fixing.
I think of the idea I am describing as a structured technique to break your old habits, and keep focusing.
I would be interested in discussing and investigating some rules around when this shifting should be done, and where the new “starting point” then should be moved. Perhaps it would be possible to set up a well-defined set of such rules?