A human Centered Approach to developer productivity | IEEE Journals & Magazine

Cultivating Talents could be hard, retaining them is harder.

In the following lines A study that discusses developer productivity and how its solely connected and affected to humans behavior and feelings. BY treating Software Developers as a humans and set metric accordingly, hopefully, it will provide better understanding and lead to more supportive decisions.

Enjoy my long summary below, Muhammad.

.....

Measuring the productivity of software developers is inheritently difficult; it requires measuring humans doing a complex, creative task.

They are affected by both technological and sociological aspects of their job, and these need to be evaluated in concert to deeply understand developer productivity.

We need to reinforce that software engineers and developers are human and productivity tools should support making their jobs easier as opposed to turning them into productivity machines.

Decision Maker hope to see a single metric that clearly goes up or down (and they want “up” and “down” to map unambiguously to “good” and “bad”). Alas, we frequently disappoint them, not because of the estimated effect of their system, but because of the uncertainty around such effects; uncertainty that comes from the fact that measuring developer productivity is inherently difficult.

Why is it so difficult to measure developer productivity?

1. Engineers are humans, and humans are inherently messy.

2. Engineering is a complex and creative task.

3. Measuring the productivity of any knowledge worker is generally a hard problem.

There are many things that, in combination, will influence how productive a human will be at a task.

1- The characteristics and limitations of human decision-making processes and memory:

Humans reason in different ways at different times and may select a reasoning

(for example, time pressure and incentives can push a person into thinking “fast” or “slow”)

2- The complexity of a task and whether that task is essentially complex or accidentally, so We can reduce complexity (and therefore increase productivity) by removing accidental complexity.

3- The team of other humans that one needs to work with to accomplish the task: In addition to the dynamics of the team members, factors such as geographic and time zone dispersion will affect how people communicate, and factors such as a mix of prior experience affect technical mentorship and institutional knowledge.

4- The organizational and business context in which the human completes the task: The way that projects and people are organized can impact productivity (Conway’s law).

Organizational incentives can also impact productivity: if delivering software fast is rewarded more than delivering software that is reliable, that pressure will shape how work gets done (and what the output looks like). It also shapes the very definition of productivity in that context.

5- The environmental, social, and cultural context in which the human completes the task:

Whether they do it overtly or covertly, individuals bring a whole self to work. They bring their sex, gender, race, ethnicity, nationality, religious background, height, weight, personal beliefs, age, and choices in hairstyle, clothing, and music to work. This introduces a whole other level of complexity to their work and work context.

Additionally, the state of the world more broadly (whether it be a global pandemic, geo-political events, press releases from the company, or election results) can change how an individual interacts with others and whether that person might be distracted by outside forces or more sharply focused on the tasks at hand.

These problems are not specific to software development, yet they affect a developer’s ability to be productive. Too often, however, people seem desperate to separate “human problems” from “technical problems.”

Both Technical and Human problems intertwined for example :

- It’s widely accepted that having a faster build speed improves developer productivity.

We see evidence that this effect does not happen because a developer sits idly by, waiting for the build to complete. Rather, it occurs because when a build is sufficiently fast, the developer is likely to stay in flow and retain the context of the task. If a build is too slow, a developer will make a very human decision and context switch away to a new task. The developer will also take longer to resume the task when he or she switches back because of the need to regain the context of the task.

- Developers, as humans, are subject to unconscious biases that may affect how they interact with others through bug reports, design docs, and code reviews. These biases may improve or degrade their own—and others’—productivity and experience. While one could argue that they constitute a “human problem,” we can also mitigate such biases with tool changes, such as anonymous code reviews.

One good reason that we continue to employ humans as software developers, despite all of the messiness described previously, is that humans are good creative problem solvers.

However, engineering is not a linear or predictable process, and when it is, we consider it “toil” or “boilerplate” and automate away the predictability. This is diametrically opposite of stamping out parts in a machine shop, which is linear and predictable (within some tolerances). So is painting a house, or assembling a rocket, or shoveling coal. Additionally, success in these activities is measurable and unambiguously understood. More coal shoveled is better than less coal shoveled (strictly from a coal-shoveling-productivity point of view). Further, the solution in these examples is about the production of uniform, interchangeable outputs. One pound of coal is pretty much indistinguishable from any other.

Not so for code:

- Software engineering is not algorithmic

- The output of software development is not known from the start

- Software development is not about the production of uniform, interchangeable outputs

Similar to the assertion that developers are human, the assertion that software engineering work is nonlinear and unpredictable is often met with agreement. But again, we see attempts to simplify engineering work to make the problem of engineering productivity more tractable. This simplification leads to failures to treat engineering as appropriately complex and creative in practice. For example:

- Conflating throughput with productivity: One might count the lines of code written by a developer in a certain period and calculate a simple output per unit time “productivity” measure like lines of code per minute. Pounds of coal shoveled per hour will tell you which shovelers are the best shovelers; lines of code per minute will not tell you which software developers are the best software developers.

- Assuming the built product is the right product: Some code that gets submitted and deployed is terrible. It might have performance issues or introduce bugs. It might be brittle or scale poorly. It might be difficult to comprehend, modify, or maintain. It might even work perfectly, yet be the wrong market fit. Part of productivity is not just the output but whether it was the right output to build.

- Assuming work that doesn’t result in output has no value: Software developers do a lot of cognitive work. They think through a problem, they look for analogous solutions, and they learn what tools, libraries, and technologies are at their disposal and how to use them. Problem solving (because that’s what this really is) involves a bunch of work that doesn’t result in an immediate objective output, is hard to measure, and may pay long-term dividends in productivity. Maybe.

Software engineering is complex and creative. It is problem solving at its core. It’s pretty much nothing like shoveling coal, and any attempt to treat it similarly in hopes of understanding developer productivity is going to miss the mark.

To conclude, We need to think about measuring productivity in a holistic and multifaceted way, not in a reductionist, unidimensional way.

Accordingly, we need to measure productivity using more than one metric, and we need frameworks for selecting metrics (for example, SPACE from Forsgren, that enable us to understand tradeoffs. We must think about productivity both in the short term and the long term; for example, we need to understand the effects that biases against underrepresented groups have on developer productivity in terms of getting code submitted and also on retaining skilled employees by treating them fairly and affording them the same opportunities that others enjoy.

We also need to remind our stakeholders that developers are human. Well, not remind perhaps—it’s not something that’s forgotten so much as overlooked. We must keep the fact that developers are human in focus as we create metrics and measurement strategies. It’s critical that developer productivity metrics are human centered. This makes the problem harder (as we’ve discussed), but it’s also the only way to do the problem justice and make real progress.

Summarized from the source material [https://ieeexplore.ieee.org/document/9994260]