Assert-first, Backwards directed, Completion assisted Coding

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.

Bowling Kata “solution”

One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:

  • A bowling machine want to report the number of pins the player strikes down for every roll the player does
  • A bowling player want to see the resulting score of a completed game

It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…

We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :

Refactoring with red bar?!?!?

We have been running the Coder´s Dojo Sweden during the autumn, and yesterday we started the spring sessions. One of the interesting observations that we have made is a follow-up on a comment that I made on Robert C. Martins page about the Bowling Kata.
The observation was that if you follow the rules “refactor only in the green” (you may only refactor while you have working and passing tests as your life-west) and “only develop new functionality in the red” (while you have a failing test for that functionality), you will inevitably end up with a situation that your new functionality driving test case forces a re-design, right?
It may be obvious to most of you out there, but we couldn’t find a single mention of how you are supposed to solve that predicament. We surely do not want to do a redesign with a failing test, the green bar is our safety net. Of course you could keep an eye on which tests are causing the red, but that is tedious and error-prone.
What seems logical is to temporarily get rid of the failing test, which you can easily do by commenting out the failing test. Simple, right? And possibly second nature to seasoned TDD:ers. But if so, why has there been no developmen of tools support for this? I could easy envision a “disable test” feature in the Eclipse/JUnit GUI…

Fifth Dojo, and still learning…

Today we ran the fifth Coder’s Dojo. Still the same Bowling Kata in Java and Eclipse (oh, I love that IDE!). This time we where only four, which allowed each of us a lot more driving time, which was fun.

This time we managed to get through the whole Kata, and even found some time to discuss one of the issues bothering some of the participants already from the start, namely error checking. Andreas and I went down that path while on the flight from the Agile Business Conference 2006 and had some learning to share. The main point being that error checking, like checking for score() being called before the game is finished (remember, the user stories actually calls for the game being finished) has to be made explicit, obviously driven by a user story (the user in this case being what ever actor is interested in such a message).

But, the most interesting thing was that we where very explicit about doing a refactoring to get a design which is better suited to fit new functionality into. I think we actually made a few steps better than Uncle Bob’s original. That feels nice 😉

Organisational Refactoring

I have worked in, or in relation to, multiple large organisations. They have all been organised in functional or compentence stovepipes, most adding a project work view across, resulting in a two dimensional hierarchy.

I have always felt that this was not a good way to organise people, or work. I dislike the common project model, for reasons that I might come back to, but my main objection to the matrix organisation is that the strongest binding force between people is working towards common goals, such as the delivery of a developed system, not their function or competence.

Every time we organise people according to competence or function, we will introduce a need to do detailed activity planning, estimation and resource allocation which makes it almost impossible to be responsive to any change in the environment of the development. This is one of the main reasons that rigorous planning more often hinders a project, particluraly to become agile and responsive. For any change the detailed planning of activities allocated to persons has to be updated.

Project planning in the traditional sense, like what is supported by project planning tools like Microsoft Project, is based on the idea that there are activities that can be allocated to multiple persons/resources, e.g. 10 carpenters working full time on the same activity, when in fact most development work is divided into tasks for which a single person is working a fraction of his/her time. This fact makes detailed planning of development work a nightmare, not to mention the follow up. It has also been shown that design is inherently different from much other work in that it often is comprised of selecting one activity, of several possible, to work on, it is this that is the competence of the designer or engineer.

Organising people according to function also induces a sense of protectionism within each such function. “We here at accounting/testing/acquisition…” This often is counterproductive since many such functions have other agendas than the total enterprise, leading to sub-optimal activities.

One way of addressing this problem is to describe the processes so that they encompass the whole enterprise. Again, this works fairly well for some types of organisations, e.g. those which rely on workflows such as insurance companies. And again, development stands apart, there is no workflow that start with the customer requirement and ends with a shipped system.

For a long time I have belived that the organisation is an important view of the enterprise, and that there exists organisational patterns and anti-patterns. And after having read Martin Fowlers book on Refactoring I realized that organisations probably could be refactored too. Unfortunately I have never had the opportunity to work with this issue, but recently I visited Organisational Patterns by Coplien&Harrison. Unfortunately it focuses on Agile Software Development, (although they admit to have opted for “agile” from a marketing perspective) and not on Development Organisations in general, but since the total text of the book is available I thought I’d share this link. It is interesting to see that they present organisational patterns as an alternative to classical improvement targeting the process.

I have yet to read the whole book, but even the introduction is interesting, particular the notion of the four styles of software development, of which “agile” is the fourth and current, and its connection to social styles. I hope to have time to read the whole book in the near future.

Perhaps with this set of patterns the idea of Organisational Refactoring can come true.