Productivity over perfection

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.

5 thoughts on “Productivity over perfection”

  1. Your example about a team spending 5 minutes choosing a variable name is interesting. In my point of view, if you can’t find a correct (not perfect, just correct!) name in a few seconds it means that you’re not capable of explaining what your code does. If you’re not capable of that, then even if the thing is “working” and usable (But who knows how if the person that produced it can’t even explain it…) it’s not done. I personnaly believe that in software development, something that can’t be reasonably understood by a team member is not done.

  2. @Julien – the debate on our team is usually because we *do* understand what the code does but we are struggling on the name to make sure that someone else will understand it in a few weeks time. Our typical codebases are worked on by 4+ developers and the people change frequently (Test Driven Development and Pair Programming and shifting teams) so the emphasis is definitely on quality and maintenance of the code.

    1. I think I agree with Julien. Spending more than a few seconds deciding on a name is a waste of time. I think that you are trying to pack too much information into a very narrow channel (see in-band signalling). I think that a good name is important as names convey intent, and it is important when changing code that you understand the original intent — especially as buggy code does not fulfil the intent. However, a perfect name is a waste of time…trying to signal what a variable is doing with a name is, in the end, pointless. Like comments they might be good for a general idea but if you want to really, really know what the code does: you have to stare at it line-by-line until you understand it. There is no other way.

      1. Our goal is to never have to spend more than 5 seconds review 1-2 lines of code … if more time is needed then it is too complicated and should be made simpler.

        This works well in really high quality environments where lots of people will read the same code over and over again (large teams, lots of different eyes).

        A little different but it works for us. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s