It is well known in the world of management that phrase of the physical Lord Kelvin that says: “What is not defined can not be measured, what can not be measured, what can not be improved, what is not improved, always degrades” , metrics have been part of our lives for long time and are tools that support decision making, help identify risks and generate alarms that allow us to react or seize opportunities at the right time.
“What is not defined can not be measured, what can not be measured, what can not be improved, what is not improved, is always degraded” — lord Kelvin. Compartir
When the software metrics are used properly, they anable a more strategic leadership style, focusing the efforts in the places where the impact will be greatest, however, as the Heisenberg uncertainty principle suggests, the observer modifies the observed and when the result depends on the people I will always get more of what I measure, in other words, the way people act is determined to a large extent by the way we measure them and in the end the culture of an organization is the reflex of what people do, looking at it from another perspective, software metrics are part of and help create the organizational culture. For this reason it is not only important to measure, it is much more important to know what to measure, in what context and to react appropriately to the information provided by these metrics.
The way people act is influenced by how we measure them, metrics are part and help create the organizational culture. Compartir
the metric is not the goal, the goal is to understand and improve.
The software metrics are much more valuable when they show us an unexpected reality that when they are green, think about the alerts of a car, all the time they stay off, they only turn on when there is a problem that I have to review. In organizations, metrics are often used as indicators of the results and management of leaders, leading people to have an excessive focus on numbers rather than improvement, making the goal have the metric in green.
Consider the following example: A company wants to make the process of customer service more cost efficient and they notice that one of the most expensive elements is the service line, as a strategy they establish a metric of the duration of the calls. Some time later they noticed that the service times decreased, but in doing so, the costs of customer service increased because now the agents do everything possible to finish the call on time in order to meet the metric, leading to cutting the call even without having solved the problem of the customer. This not only causes dissatisfaction but also increases the number of calls to the line, causing the final cost of the line to increase. In this case, the performance metric of the process used did not have the correct effect.
Another very common example in the world of development is to use the code coverage metric as a software quality metric, leading developers to have many automated tests that cover 100% of the code without the desired effect of having higher quality software, on the contrary you only get many automated tests that do not ensure the quality of the software and are more difficult to maintain over time, increasing the problems of quality and productivity.
Or think about the use that is given to the code quality metrics generated from static code analysis tools. Many times the teams are asked to have a low level of technical debt without understanding the ¿Why? It is important to solve the problems reported by these tools, ultimately leading to more difficult software to maintain without a positive impact on quality attributes.
The goal should never be the metric, the goal is continuous improvement, collaboration and learning. Compartir
Tell me how you react and I’ll tell you how I act
Metrics should allow conversations between leaders and collaborators that generate concrete actions when necessary, not when it is too late. When a leader reacts negatively to a metric that is in poor condition, he sends an implicit message to his collaborators and because people can easily influence the metrics, this leader can be sure that over time he will only see the green metrics. Cosmetic metrics that only serves to fill the ego but does not reflect the reality of the organization and therefore does not allow to act, it is the same thing that happens when a child says something bad to his father and he reacts violently, this child will not say anythig to him anymore, but this does not mean there are no problems.
Metrics without the correct context are dangerous and only serve to generate alerts that may not exist. It is always important to ask: Why is this metric important? What is it really telling me? How can I help as a leader so that the situation changes? Do I really need it?
Based on the famous phrase of Peter Drucker:
“Culture eats software development metrics at breakfast”. Compartir
A problem is the gap between expectation and reality.
Reality is naturally imperfect, the world is imperfect, human beings are imperfect, but our minds create mirages of ideal situations about how things should work. The problem with this is that we all value different things and therefore from our observer there will always be something to improve. By doing micro management you can find many more problems because the gap between expectation and reality will be much greater but due to time constraints there will never be enough resources to improve all situations that are identified, so why do you do micro management ?.
That is why it is necessary from the management perspective to know what to measure in order to have information with which you can really act strategically. The human being needs models that allow him to understand reality, there is no perfect model, there are only useful models for each person, metrics have the same effect, there are no perfect metrics, there are only useful metrics for each person.
When we build Quind we seek to close the gap between the managers and the technical teams of software development, generating metrics that allow non-technical people to understand the status of projects with as little information as possible and without knowing the technical details. We look for more conversations in organizations, which allow both managers and teams to react at the right time, understanding the level of technical excellence of the software built, the impact it has on the reliability of long-term systems and on the potential efficiency of the developers. This is Quind, a platform that closes the gap between managers and developers interpreting all those metrics that are complex and difficult to understand to emmit a clear and precise concept that lets you know if the software is well built.
Quind, reliable and well-built software with effective teams!
