Mark Needham

Thoughts on Software Development

Think a little, code a little

with 6 comments

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.

Be Sociable, Share!

Written by Mark Needham

August 5th, 2009 at 12:13 am

  • I agree completely. Lazy coding often also takes the form of a “coding frenzy” where the euphoria of programming combined with the anticipation of the client’s happiness when a project is delivered early can cause a situation where the programmer hurries in order to create the single deliverable at the expense of the clean code base. Unfortunately, this often has the opposite of the desired effect later on in the application lifecycle when the technical debt starts to catch up with you, and suddenly your maintenance time is increased and time between releases is decreased. There’s most certainly a balance. One extreme assumes the future, while the other ignores it. We certainly have a limited view of what’s ahead. Assume neither nothing nor everything, but assume something in between. This is what “think a little, code a little” sounds like to me.

  • You’ve just named my coding strategy. I seem unable to design upfront. On the other hand coding some general idea gives me an in-depth of the failures really quick. Of course, I understand that other people may feel different and prefer formal design steps.

  • Pingback: Twitted by pramatrdev()

  • I’ve always been in favor of what I term “Evolutionary Engineering”, where the project evolves and changes during the development cycle as problems are encountered and resolved and new ideas come about from the growth of the code. I usually like to take a fair amount of time at the beginning thinking about my coding solutions, how I’m going to structure things, and the overall architecture, then I start coding with an eye towards knowing that things will very likely change as I move forward. I build prototypes which provide me with rapid turnaround examples of specific functionality, which can then be modularized for easy implementation later, then I build the framework which allows me to test the basic framework. I always assume that a client is going to want something added that’s out of scope of the original spec, so this keeps me from finalizing too much early on. Building in discrete steps allows the project to evolve. I like to consider all projects to be fluid – the spec is a guideline, but never set in stone. New ideas can come along at any time, and what looks good on paper doesn’t always (in fact rarely) translate into a usable end product. I often provide suggestions to my clients during the development process of improvements to UI or functionality that have arisen from the results of prototyping and testing particular operations and overwhelmingly these changes become a part of the evolutionary process resulting in a much improved end product.

    The ability to think-code-think-code and allow the project spec to be fluid and malleable is essential, in my opinion, to being able to deliver not only what the client asked for in the first place, but also all those extras that turn a good project into a great one and help to generate return business.

  • Pingback: [ ] » Think a little, code a little..()

  • @David the coding frenzy you describe sounds quite similar to what Uncle Bob would refer to as ‘creating a mess’! Which I suppose is exactly what it is.

    I’m not even sure if people consciously do it or just get dragged into that practice when they feel the pressure.

    @Niilo I like the idea of delaying finalizing decisions so that you can change them later on. It’d be interesting to know what techniques are useful for allowing us to do that successfully.

    I like your last paragraph, hadn’t thought of it like that before but that’s quite insightful.