August 1, 2007

...Learn TDD with Codemanship

Economical, Iterative & Feedback-driven Software Development

I'm becoming increasingly uncomfortable with the "A" word.

Frankly, it's become so commercialised in the last couple of years that I feel just a little dirty when I use it. It's also all but lost it's meaning - if it ever had one. When I say "Agile", I suspect I'm not thinking about the same thing that other people think about when they hear me say it.

So I'm resolved now to say exactly what I really mean. When I said before "Agile Design", what I actually mean is iterative and predominantly (but not completely) feedback-driven design.

I understand what this means. It means that the design emerges through successive cycles. At the beginnning of each cycle I do a little up-front planning about what kind of design I want to achieve, then at the end of the cycle I test the resulting code and feed what I learn back into the up-front planning of the next cycle.

I can get my head around not only how this process works, but why this process works. To me, that's critically important - especially since it means I now know what levers to pull to steer the design process more effectively.

For example, frequency of feedback is one lever. If each cycle takes 4 weeks, then I have found that shortening that to 2 weeks speeds up the evolutionary process and we tend to reach a better design sooner.

Quality of feedback is another lever. "Constructive feedback" is feedback that helps you make something better. Remember those games where someone would hide something in the room, and you would look for it. If you were closer to where the prize was hidden, they would say "getting warmer", and "getting colder" if you moved further away. This is how the evolutionary search algorithm works. It requires feedback that tells you when you're getting closer - or further away - from your goal. The better the feedback, the less cycles it can take to reach the target.

Shorter cycles. Less cycles. Both mean potentially achieving a better design sooner. (To a point, of course - you need sufficient time to take in the feedback and plan the next cycle, or else you end up going nowhere.)

Another lever is the effectiveness of your up-front design planning. I'm really sorry about this, but I'm going to have to resort to another golfing analogy. To me, up-front design is like teeing off. The better your first shot is, the less subsequent shots you might have to take. But there's a point where, no matter how much care you take, it won't necessarily get the ball any closer to the hole. We have to strike the right balance between taking care on our shots and leaving time for those unavoidable subsequent shots.

In design terms, this means that we should do just enough up-front design, striking a balance between the effectiveness of our plans and the time we can afford to allow ourselves to spend on them. I have discovered that this is a balance you have to find. Experiment and measure the results. At what point does up-front design planning stop benefitting you? Of course, the way you do design also plays an important part. Experience has taught me that the more assumptions I can test before sitting down to write the code, the less time I waste on avoidable rework later. Adopting a rigorous, collaborative and test-driven approach to design seems to work especially well for me. I tend to do a good chunk of my learning at the whiteboard, and that means less feedback cycles are required to "get the ball into the hole".

Another factor usually associated with the "A" word is economy - specifically, the reduction of waste. This might mean constantly refactoring out duplicate code, or it might mean opportunistic reuse, or it might mean process automation or code generation. Realistically, it means a combination of all of these things. It certainly means not wasting time on anything that doesn't add value - like documentation that won't ever be used, or wasting months on detailed long-term plans that will have to change before the ink's dry.

So, from now on I will try to say "economical, iterative, feedback-driven software development" instead of falling back on the "A" word.

Okay, I might try and come up with a slightly friendlier description - just so I can fit it on a t-shirt!
Posted 13 years, 4 months ago on August 1, 2007