I know I’m preaching to the choir now, but a good programmer is distinguished from a bad one by efficiency. And the first thing that comes to mind when we hear the word “efficiency” is the time spent on implementing a particular feature. For example, when one developer does something in three days, and another one — in six days, then a small amount of arithmetic calculations reveals that the first developer is twice as effective as the second one, isn’t he?

No! This criterion will be correct only in the short run and totally wrong during long-term development.

The right way to test a developer’s performance is to see how he handles several typical (repetitive) tasks. Each next task of the same type must take less and less time. You can try to derive a certain formula of reducing the execution time of a next task and use it to evaluate and compare the effectiveness of developers in your team. The so-called developer’s efficiency ratio. Well, for example, each next task of the same type should take two times less time than the previous one. Until a certain point, of course.

Becoming more efficient

We could talk a lot about how to achieve efficiency gains and speed up the development process. This time we will offer you a couple of analogies for reflection.

Do you remember the idiom about the sharpening of the ax and deforestation? The one where an abstract developer has no time to sharpen an ax, because he’s too busy chopping wood.

The problem is obvious, but the solution is not always so straightforward. There is a flipside here — premature ax sharpening. The ax needs to be sharpened when it is clear that the costs of sharpening the ax will pay off by the speed of deforestation.

And to check it out, you need to:

1. Find out the speed of deforestation with a blunt ax. To this end, you need to do the task at least once before any optimizations. No need to implement a separate library and introduce extra abstractions till then.

2. Understand the characteristics of the ax, know what will happen after sharpening. The initially written inline solution, built within the current architecture, will fully make it clear what and where you can later replace and refactor.

3. Know the next time you need to sharpen an ax. It’s impossible to make all the code completely polished at once, but it is never necessary. It is much better to take care only of a specific task each time when refactoring. Your goal is to shorten the development time of this particular task the next time, say, twice.

There is another similar popular idiom. It says something like: “It’s better to spend the whole day building an airplane to fly to your destination in five minutes, than to spend the whole day trying to run there.” But the “ax” and the “plane” idioms describe different cases. The “ax idiom” tells about different tasks of the same type, while the “airplane idiom” — about routine processes within the same task.

Originally published at Riter Agile Blog.