I recently came across an interesting post by Frans Bauma entitled 'Think first, doing is for later' which was linked to from Jeremy Miller’s blog entry about incremental delivery and continuous design.

Right now I find myself in favour of Jeremy’s approach which is more about writing some code and then getting some feedback on it and then writing some more code instead of spending a lot of time thinking before we write any code.

My colleague Brian Guthrie referred to this approach on twitter as 'think a little code a little' which I think sums it up pretty well.

The example that Frans gives is centred around algorithms so I wonder whether a bit of up front design to work out that we understand the algorithm is necessary before trying to code a solution.

On the other hand something that we’ve noticed in particular at coding dojos is that putting an idea into code helps to generate a rhythm of progress which we’ve struggled to create just by talking about the way that we think we can solve a problem.

Even with algorithms I find that I understand them more easily once they are written in code rather than just spoken about conceptually or drawn out in pseudocode.

My current thinking is therefore that I’d prefer to spend a little time thinking and then get the idea into the code more quickly even if that means we make more mistakes and have to do a few iterations of the code to end up where we want to be.

The alternative is to spend much more time thinking up front and then maybe getting to the solution more quickly but maybe realising that our idea doesn’t work once we get into the code which means we haven’t got that feedback as quickly as we might have been able to.

A similar idea is discussed in Domain Driven Design where Eric Evans points out that while a model that we come up with on the whiteboard may seem perfect that doesn’t actually matter if we find out that the idea doesn’t quite work when we try and put it into the code.

Uncle Bob has also written about the difference between no design up front and spending some time thinking about what we want to do and while some of the activities that we would do while thinking through an approach would be similar to those Frans' identifies, I don’t feel the planning would go into quite that depth.

There is definitely a need for some thought in the process, however - what I refer to as lazy coding is the extreme of what happens when we don’t think at all about what we’re doing and that leads to code which is completely unmaintainable and very difficult for both ourselves and our colleagues to understand.

Often when we do this type of thing we like to refer to it as 'technical debt' but I quite like the distinction Uncle Bob has been making on twitter between technical debt and just creating a mess.

I find the former is done as a result of us thinking about what we’re doing and realising that we need to take on a bit of debt with a shortcut now and then fix it up later. The latter on the other hand seems to occur when we don’t think about what we’re doing and just do the easiest thing possible.

An idea which I do like from the post is the idea of documenting why we made a certain decision.

From my experience quite often that information just remains in the heads of the people who made the decision and then we are relying on their memory when we come across a bit of code in the future and want to know why it was written in a certain way. In Dan North’s language this would seem to be the job of the project sharman although I guess it wouldn’t hurt to have some of that information written up on the project wiki as well.

I would still probably do that bit of documentation after we’d proved that the code actually worked rather than before writing any code which is what seems to be the approach.

I guess this approach does work for Frans so there is certainly some value in it from that perspective but from the projects I’ve worked on working in smaller increments has worked more effectively for us.