Back to archive

Speed of writing code has never been a problem

Published / Evgeniy Balashov

The Mirage of Optimization

As the creator of the Theory of ConstraintsEliyahu Goldratt — said:

“An hour saved anywhere other than the bottleneck is a mirage.”

  • optimization outside bottlenecks: improving the work of tools, processes, and people that are not constraints leads to more work in progress and higher costs
  • focus on constraints: a system’s effectiveness is determined by the performance of its weakest link
  • exploiting the constraint: instead of optimizing everything, you should first identify and eliminate the bottleneck. Real savings appear only when the bottleneck itself is optimized

In other words, when you optimize a stage that is not the bottleneck, you do not get a faster system. You get a less efficient system.

How Much Time Do Engineers Spend on Code?

Various studies analyzing engineers’ work show that the share of time spent writing code relative to other stages ranges from ~10-16% to ~50-65% in small early-stage projects. In the study Microsoft Research — “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era”, engineers report an estimate of 11%. At the same time, in their “ideal week” they would like to spend 20% on writing code and 15% on technical design.

The 2022 Global Code Time Report gives a median figure of 52 minutes per day.

More Serious Problems

We will undoubtedly get a significant increase in the amount of code produced by introducing AI agents into the development process, and as a result we will amplify all bottlenecks if we do not optimize them in time.

Now we write more code, but create less quality functionality.

The Real Bottleneck

The quality of hypotheses and ideas in our backlogs! That is what should be optimized as much as possible — what lies far before the start of the development process. Too often, we are overly confident that these tasks are worth implementing in the first place.

What Should We Do?

We measure the value created for your customers, not quantitative metrics. Release frequency and the number of features in them often don’t correlate with the value your customers receive or don’t receive.

Planning is the most important stage of the pipeline – we must answer the following questions:

  • What are we doing?
  • Why are we doing it?
  • What do we consider a successful outcome?
  • How are we doing it?

Before we begin implementation.