Efficiency And Performance

In this post I will work with the following definitions:

• Efficiency: Doing more with less.
• Performance: How soon an answer comes to an identified need.

Code sometimes has problems with performance — things are not answering soon enough. It often (but not always) turns out that the code is making inefficient use of its resources.

So what do a good programmer do about that? First, he observes the program doing its work. Then, he analyzes the information that he has collected. There are three possible outcomes of this analysis: that he needs to observe some more, that there is no identifiable bottle-neck or that there is at least one identifiable bottle-neck.

It is obvious what needs to be done about the first outcome. And perhaps he needs to do the same with the second outcome, though he could also get a second opinion from someone else, or conclude that there is nothing that can be done.

If he finds a bottle-neck, he goes to work to remove it. After this, he observes the program to see whether it helped or not. Analyzing that information, he may discover other bottle-necks or he may conclude that the performance is now sufficient.

To remove a bottle-neck often involves improving the efficiency of the code. On the surface, the code still needs to do the same thing - it must not change its behavior. But to improve the efficiency, it must do this same thing with less effort. In the low-level, this often translates into not doing things that really don’t need doing. For a sorting algorithm, this could involve making fewer comparisons between the array elements. In other cases, the solution could be to do more work in one part of the program, such that other parts will have it easier. In other cases still, we make more efficient use of the CPU by introducing parallelism. The solution depends on the context.

Teams sometimes also have performance problems — we are not producing deliverables as soon as we would like. Is it a problem with efficiency? From what I have seen, it often is.

Never mind our habitually overconfident estimates, we are spending a lot of effort on things that do not need doing. And we do not invest effort in things that would make other things much easier. And we are not making full use our potential parallelism, when people are blocked on other peoples incomplete work.

So how do we address this? It appears that we try to do more work, with more effort. Not less. We work long hours, go into crunch-mode and still miss our deadlines, our feature-goal, our quality-goal.

This is backwards. We feel the pain-point but we do not observe or analyze its cause. Thus, we do not identify any bottle-necks. Without any identified bottle-necks, we do not know what to improve about how we work. And if we do not improve the way we work, then we will not deliver working software sooner.

The process is simple. Most programmers are already familiar with it. And yet, at least where I work, we are not doing it. We are not doing it even we time and time again miss deadlines, budget, features and quality.

To me, the self-optimizing team is the heart of being agile. It will on its own bring about the shorter release cycles, the customer collaboration, the code quality, the task-automation, the testing, the pairing, learning and all the other good things that, agile or not, happens to work well for the given team on the given project.