Code And Cocktails

Slow Programming Movement (Response to @marick & @RonJeffries)

| Comments


On August 3 Brian Marick tweeted [1]

Agile is a melding of a craft ethic and super-responsiveness to change. How would some explicit Slow Programming fit in?

Then, on August 4, Ron Jeffries responded: [2]

@marick I wonder if TDD might be “Slow Programming”

I also responded quickly – but wanted to take the time now fill in some more details to my response[3].

This response is based upon my personal understanding of the ‘Slow Movement’[4] which may or may not be entirely in line with the actual goals/aspirations of the ‘Slow Movement’. Also at the time of this writing I find that there is already a Wikipedia entry for ‘Slow Programming’[5] but I disagree with the description of that as linked from the Wikipedia article[6].

What Slow Programming means (to me)

To me the “Slow *” movement is about being deliberate, mind-full and sustainable. Thus slow programming would involve programming in a way that is done with thought, and is sustainable over a long term. It would not involve quick “hacking” of code to meet arbitrary deadlines in a way that cannot be kept up for weeks/months/years.

The ‘Agile’ process(es)/practices to me lead us to this “Slow Programming”. Specifically the practices of TDD & Sustainable Pace.

We all know that going ‘fast’ does not mean necessarily going ‘well’. As Kent Beck says: “If it doesn’t need to work; I can get it done much faster”.

TDD leads me to program very mind-fully. Always thinking of the next thing the piece of code must do or not do. Before TDD I would just write the code I thought was needed for the requirement. But with TDD I write the requirement as a test and then write the code to make the test pass. That leads me to be constantly thinking about the requirement; constantly questioning the requirement. I am always asking the “Customer” what they meant, do they mean “this” or “that”; and what if “something-else” happens? My code with TDD is not done more quickly than before; but in the end I know exactly what it does; and it does not more. In the past my code might do things I had not intended (for better or for worse).

Sustainable Pace keeps me from overextending myself for long periods of time. Of course when a important deadline looms I push; but through long experience I know that pushing is a double edged sword: the stress keeps me focused; but the speed reduces quality.

Programming needs to do be done very conscientiously and at a pace that can be kept up in the long term. One must always be 1) doing only that which is needed, 2) questioning the customer what is needed to ensure #1 and 3) keeping up a good pace because burning out your resources are, in my opinion, unprofessional, since it leads to worse code.

In Reaction to the existing definition of Slow Programming

When I began this blog post I was not aware of an existing ‘definition’ of Slow Programming[6]. That definition appears to be made in opposition to Extreme Programming[7] and I think that is not the right angle to take. Given that we know that requirements will always change (unless the “Customer” begins a “Slow Business Requirement” Movement) the concept of having “careful design process by a fairly small number of people who know the business well”[7] is not going to work. We must design only as much as possible to handle the given requirements, meet them; then allow the “Customer” to play with them to discover their next requirements. Perhaps this is the important part of the “Slow Programming” concept: giving the “Customer” the time to discover their own requirements – not rushing them to attempt to get all their requirements before we start programming.