In November 2022 I posted an infographic on LinkedIn that got a lot of attention. Essentially, infographic promotes direct communication between product developers and customers. People reacting in the comments brought multiple arguments against this approach. Each argument deserves its own article.
I start with the one I consider the most important one: the “productivity” argument. It says that having a separate analyst is more efficient and direct communication between coders and customers means a loss of productivity.
The productivity argument
Productivity as an economic term is usually defined as a ratio between units of output and units of input. In the software world, I translate this as an amount of customer value (e.g. useful features in a software product) per unit of work (as human effort constitutes a majority of costs in software product development).
Let’s say we have a feature that can be coded and delivered in 40 hours of one programmer’s solo work once the programmer understands the requirements. This effort remains constant in all scenarios so I will leave it out from further calculations.
Now let’s assume that this programmer, unskilled and untrained in communicating with customers will need 6 hours of direct talks with a customer until he understands the requirements.
If we say having a middleman (I will call him an analyst) is more productive then we say in other words that we will develop the feature will less human effort (input), while output stays the same. Let’s have a look at this in more detail.
Productivity of handovers
Instead of one meeting customer-programmer, we will have two meetings: customer-analyst and analyst-programmer. The total effort consumed for the software company (we do not count the customer effort) will be triple the original costs: two times for the analyst and one time for the programmer. So to save some effort, the analyst must be at least three times faster than a programmer in clarifying requirements.
Now people will tell “of course we will not have one analyst per programmer”. So let’s look at a more realistic scenario of one analyst per 5 developers.
In this case, there will be one analyst in the first meeting with the customer and there will be the same analyst and the 5 programmers in the second meeting. In other words, instead of five units of time involved, we will have seven units of time involved (five for programmers plus 2 for the analyst). To save effort the analyst must be 40% faster (7 divided by 5) than a programmer.
This however assumes that all programmers in the team are equally junior and unskilled and ignorant of the business domain. This is not usually the case – in a team of five programmers, there are usually at least a couple of them who know something about the business domain of their product. So in fact, the last conclusion should be rephrased as the analyst must be 40% faster than the fastest and most experienced programmer.
Furthermore, the picture above only describes the happy case. In the base scenario, if one of these five programmers needs clarification that takes 1 hour of effort, he can spend this 1 hour talking to the customer. When the analyst is involved, the programmer will first need to explain the problem to the analyst (2h of effort), then the analyst must talk to the customer (1h of effort), and then again to the programmer (2h hours of effort) making 5h of effort total. Even if we assume that the analyst is 40% faster in understanding and communicating, it is still 3h of effort compared to the 1h in the basic scenario.
Conclusion
Many people operate under the assumption that it is possible to clarify software requirements in one pass. Even in this unrealistic scenario an analyst needs to be 40% more locally efficient in clarifying requirements than the most skilled programmer.
In more realistic scenarios where 2 or 3 rounds of clarification are needed when programmers code the feature, having a separate analyst means spending multiples of effort compared to the direct customer-developer scenario.
Therefore I argue that having an analyst will be more productive only in rare and unrealistic circumstances and will rather need more effort than direct communication.
