You make morning coffee. Want to make 2 cups. You:
- Start boiling water for 1 cup so that the water boils early and one cup is ready as early as possible
- Start boiling water for 2 cups to cook them at the same time and most effectively?
I posted this question on Twitter and got about 50 answers. Most of the comments were either sarcastic or thoughtful tips for making coffee, so it seems I could not get my point across.
Since such a hint was not understood, I will try to write directly:
- Every day we choose between response time and performance
- We are biased towards performance (I blame Taylorism on this)
- The high price of delay, the high chances of receiving new information and the high speed of changing circumstances - all this says that you need to choose a quick response
The coffee story is just one example of the phenomenon.
The original uses the terms “ Latency ” and “ Throughput ”. I decided that the most appropriate translations in the context would be “Response Time” and “Performance”, respectively - approx. perev.
Response Time vs. Performance
Response time is the “interval between cause and effect”. Let's say I decided to go to the city center. How long will it take before I get there? Response is measured by time.
Performance is the “speed of achieving the desired result." People want to get to the center. How many people are there every hour? Productivity is measured in quantity over time.
Sometimes response time and performance conflict. Buses can carry more people per hour than cars (i.e. more productive), but I personally will need more time to get to the center because I have to go to the bus stop and wait for the bus (i.e. the response time is higher).
The relationship between response time and performance is not always straightforward. If due to the large number of people who have moved to cars, traffic is deteriorating, then response time and productivity are affected. If enough people start using the bus, then after the traffic both the response time and the performance improve.
Coffee
Let's go back to the coffee example. Here is a sequence chart for preparing cups:
And here is the "simultaneous" preparation of cups:
HEAT - water heating
POUR - pouring water into the filter
DRIP - water leakage through the filter
approx. perev.
It can be seen that the first option has a shorter response time, but the second is more productive. In what cases can this be important?
- Optimize the response time when one of the customers is exhausted without coffee and the other is not (for example, still asleep). The delay price for the first customer is high.
- Optimize your response time when a person making coffee can learn something from his mistakes. It’s better to get 1 cup of tasteless coffee and 1 cup of delicious coffee than to get 2 cups of tasteless coffee as early as possible.
- Optimize response times when circumstances may change. If any of the customers can change their minds if they want tea instead of coffee, it is better to finish one coffee and start making tea than to throw out the “effectively” prepared second cup of coffee.
Analogy
When developing software, we are faced with the equivalent of “one cup at a time or two in parallel” every day:
- Do we carefully plan all the proposed improvements in architecture in advance or do we start with one obvious?
- Do we carefully draw up a development plan taking into account all the requirements at once or do we implement one of the most important and only then think further?
- Do we carefully go through the mountain of resumes to find the best candidate or quickly hire the first candidate to replace him if we don’t work together?
The correct answer to each of the questions is “depends on the situation”. Three important aspects here are:
- How expensive is procrastination?
- How likely is it that we learn something that will make us change our initial approach?
- What is the likelihood that the task will change due to external circumstances?
A high score in each (or several) of the indicators above should suggest that you should prefer a short response time for high performance.
An attentive reader may notice that the word “carefully” is used in all the examples above. But even the most careful planning has its limits. From a certain moment, planning ceases to work at all, and only work with subsequent debriefing leads to a result. I think that the illusion of the ability to think absolutely about everything in advance makes us biased in favor of performance.
Intuition
Choosing a low response time even at the cost of a (possible) decrease in productivity is one of the lessons that my generation learned from their mistakes. I wrote about another such lesson, discussing a basket of options . It seems that both of these lessons are forgotten today.
Contrary to urgency, learning from mistakes and unpredictability of circumstances is an exception, not a rule. I hope you understand this faster than I did in my time.
Inefficiency
The title of this article is a pun. Productivity, which apparently seems effective, is often ineffective. The quote from Peter Drucker comes to mind : "There is nothing worthless than effectively doing what should not be done at all."
But the title can be read differently. Focusing on response time, we get feedback earlier. Learning and adapting to change leads to less labor and, therefore, to greater efficiency. Each individual part of the work is inefficient (compared with a certain theoretical maximum), but the work as a whole is effective.
In my world, response time is dominant. Often. But not always.