Agile is all about choosing productivity over perfection.
There is always more work than you can get done, so why spend a lot of time creating what a friend of mine calls a “perfect garden”? Wouldn’t you rather get it working and move on to the next thing? For a lot of developers, the answer is “no”; they would rather spend time thinking beautiful thoughts and — most of all — writing frameworks.
I hate frameworks. I’m beginning to grind my teeth as well when people say “pattern”; they are almost always polishing rather than producing. I’m sure patterns do a lot of good, I’ve only ever seen them used to justify doing some work on the perfect garden. “Wouldn’t it be better to invert the logic? Unmilking the cow is such a laboured metaphor”. Puh-lease. Ok there is a point at which your inappropriate logic or database schema turn “laboured” into “burdensome”, but let’s clip a path through the bushes until the design is adequate again; then get back to real work.
Let’ s be clear; being productive is not hacking. This is choosing to work on the most important things. As soon as it is done then it is time to deploy it and move on. Of course, you can’t keep doing this without some sort of supporting framework. The traditional agile things good, flexible OO design; automated testing and continous build integration.However, mostly it is about the kind of productivity that you get from task management systems like Getting Things Done. It is about realizing when a thing is done. And when it is not tested and horribly structured then it is not done. However, if you have completed the task but not refactored it into a framework using an WCF Abstract Factory-Factory then is is done. Move on. Move. On.
How to combat this “perfect garden” is the tricky thing. For me, imagining that you are a self-employed programmer is very instructive; there are millions of things you need to be doing and a team spending 5 minutes choosing a variable name isn’t one of them. At the end of the day shipping code that works and does something useful is what counts; you just need to have the vision to remember that tomorrow you’ll be back working on the same bit of code. Think about it from a sales perpective: if it costs $100 dollars to add a feature that will only ever attract $25 of sales, then skip it… until a rainless day and all the $1000 dollar features are implemented.
Of course, developers love perfection. Of course, if things weren’t mostly perfect when you write a program then you won’t have written anything. But how can a design be perfect? It can’t of course; it can only be inadequate or adequate.
And having just realised that I’m trying to perfect this article by spending 10 minutes looking for the perfect closing line; I realise that I’m done.
