Why a focus on efficiency in software development can cause a lot of damage

In creative professions, striving for efficiency can have the opposite effect of what it intends. A call for the right approach to efficiency in software development.

Efficiency versus effectiveness

Efficiency may only play a role when we are sure that the results of production have value. In software development, the risk of not fulfilling this premise is high. Either products or functions without value are developed, or they would have had value but were not implemented well enough. In both cases, a massive waste takes place. Efficiency in production is secondary here. The priority is to ask the right questions and make good decisions.

Waste versus investment

Part of the work during decision making is to explore and validate ideas, opportunities and strategy options. Many of these end up in the reject bin. Nevertheless, although no software was produced, the work had the value of insight. This is valuable because much more waste or harm would have resulted if implemented instead. Likewise, a doctor who doesn’t believe treatment is necessary after an examination wouldn’t be accused that his work was wasted.

Efficiency in decision-making

So how to assess whether this important work of making decisions and finding solutions has been done efficiently? Just as managers are generally not judged by the number of decisions they make, but by the selection and quality of those decisions, product managers, designers or developers cannot be judged by quantitatively measurable factors in the process. Who can judge whether all the strategies, concepts and solutions were good or just average, without having been involved in the process themselves? How to decide if two decisions made quickly are better than one with more value? And what if there had been an even much better option that was overlooked?

Measuring efficiency in software development

Leaders with a lot of experience in software development know that outstanding employees or teams can be many times better than average ones. But you can’t measure it with hard, comparable data. Creative work can only be measured by qualitative factors:

• Source of excellent questions and ideas
• Quality of decision making
• Perceived productivity in decision making
• Earning trust and respect from key stakeholders

Improper methods for efficiency optimization

Nevertheless, there seems to be a lot of pressure in many places to still provide metrics on efficiency. Unfortunately, they are all useless. For example, Team Velocity is a popular metric that measures the relative performance of teams over time. For planning purposes it may be an important reference, but as a statement about efficiency the metric is useless. In software development, performance says nothing about the result. You could equally well measure how many lines of code have been written or how many graphic pixels have been moved.

Other approaches face the same problem. When teams are compared in this way, the measured metric is likely to improve without any perceptible change in the outcome.

Meaningful methods to increase efficiency.

To teach an apprentice, bring in the master. The apprentice has to learn first. Leadership coaching, mentors, internal or external experts, continuing education or better and more experienced employees are the solution to significantly increase efficiency in teams. Productive and experienced professionals know what needs to be done and can help less efficient employees. At first, these measures do not sound like efficiency optimization, which does unfortunately not make the discussion any easier.

When striving for more efficiency in teams, further methods have proven to be effective. They help more by evaluating the situation than by providing a solution. Therefore, they need teams to know what has to be done in order to optimize:

Limit work in progress.

Also known as WIP-limit. Since moving from one task to another on a regular basis is not efficient, teams can set a limit for themselves. By doing so, they “force” themselves to think about how they can work more efficiently. Reduction of dependencies or a stronger orientation towards the bottleneck in the team comes into focus more quickly.

Increase frequencies and degrees of automation

Frequencies and degrees of automation in learning-, development-, test- and release-processes can be increased step by step. The higher the frequency of these processes, the more professional and efficient the processes need to be. Teams that deliver software every day while ensuring high operational reliability simply cannot have inefficient test and release processes. Also, dependencies on other teams or stakeholders cannot be maintained at high frequency.

Reduce technical debt

Removing technical debt does help to increase efficiency in changing existing code. In addition, inefficiency trough technical debt increases disproportionately rather than linearly.

Parallel analysis and discovery cycles

Those take place prior to, independently of and in parallel with the implementation stream. This guarantees that despite the uncertain duration and outcome of evaluations and decisions, a constant and uninterrupted implementation of secured value-added work can take place without interruption.

This article was first published by Traian Kaiser on Medium