The Space of Developer Productivity

The problem starts with name. Developers are creating not producing. They don't make the same widget every day. When you are measuring productivity instead of creativity, you hinder creativity and therefore output.

A better discussion is about what happened in the late 1980s and lasted until the dotcom bust: empowerment. The empowerment movement was in some sense inspired by Just In Time (JIT) manufacturing. The idea presented simply is to harness the power, or empower, line workers to halt the assembly line when line workers saw a defect. Chains were installed on factory floor assembly lines and line workers would pull the chain when they saw quality defects. This is called total quality control, or TQC. Everyone is empowered to be do quality control and thus TQC. There is a lot more too it but that's the gist. The Harvard professor who invented JIT couldn't get Americans to buy into his idea and had to finally find adoption in Japan. Thus Japan's rise in car and electronic quality and ability to cut costs by having less defects. Empowerment took on many other flavors eventually where Tom Peters of FedEx fame empowered delivery drivers to change schedules and do other things to make delivery times. Empowerment then went into quality of life overall with on campus gyms, on campus day care, bagel fridays etc. The hay day was the 1990s where it seems a new management book every week came out promoting new ways to empower employees and to upgrade management processes with such things as open door policies. But, and here's the but, Americans love tyranny. They always have. The so called captains of industry were never much interested in the power sharing that the word empowerment implies and after the dotcom bust in 2000 the empowerment trend was soon on the defensive. S** rolls downhill, cajoling, and other forms of tyranny are what American management know and love. And that's where things have returned. Management of 2021 has more in common with the late 1970s than the late 1990s. Do as your told reigns king. Know your place. The elephant in the room that this article does not address is that as long as corporate America and the world continues to use an authoritarian, top-down pyramid structure of power then the limits of that structure apply. The empowerment movement has all but been banished and that fundamental, tyrannical space confinement of top-down, micro-management of authoritarianism by threats and intimidation cannot be addressed by any amount of bottom up discussion. Nothing is going to get better until those in power give it up. I actually find it amazing the the empowerment movement ever found fertile ground at all. But to be honest America flirted with power sharing for a time only when it got its azz kicked by Japan in the automobile and electronics industries. America soon abandoned empowerment because the lure of draconian power is ever seductive. Steve Jobs put the final nail in the coffin of the empowerment movement in the tech industry.

As long as there are open-plan offices instead of private offices for each knowledge worker (even in dense urban real estate markets) then please stop talking about developer productivity or efficiency.

Companies utterly don’t care. The degree to which they don’t care is so exceedingly flagrant that they use open-plan offices.

What more can there possibly be to discuss?

What if their were some benchmark projects that a team could do in about three days of work? If it provided valuable feedback on which areas the team could improve, it would be well worth the investment.

The impedance bump between this framework and the evaluation system for the rest of the company including management at most places must be pretty large.

It strikes me as the kind of thing you'd expect to see in a boilerplate programmers union contract.

My last W-2 job had a performance review system where all the metrics flowed upwards to the goals from management that flowed downward, sort of a countercurrent system. In that way this framework seems more like procedures how to do it well, than metrics you could actually use to meet higher level goals.

I don't think there's anything wrong with this framework and following it would likely result in maximal revenue generated per developer employee, but selling it to the suits will be hard.

The more elaborate the system the more easy it is to manipulate it and stretch the truth; its not a simplicate and add lightness design. And the suits know that, the more fine print the more likely someone is going to manipulate the fine print rather than execute core goals. So there would have to be a lot of trust either voluntarily (unlikely? only last until the first missed deadline or first bug report?) or involuntarily forced (again the union contract idea)

It's great that developer productivity is getting more research love, as it is not easy telling developer advocates for my solution that, you still have to tell management that they still need to work for meaningful insights.

I think solutions like GitPrime (now Pluralsight Flow), GitHub Insights (formerly Gitalytics), Waydev, etc. really gives the impression that you can easily rollup metrics for management, to help them understand developer productivity, but the simple fact is, there are so many variables, as this article alludes to.

Take the microsoft/vscode project, which is being developed at an incredible pace. If you look at the raw numbers like commits, files changed, churn, etc. with the "Velocity" metrics in the following:

https://public-001.gitsense.com/insights/github/repos?r=gith...

you can see that it swings quite wildly at one point of time. And if you only look at typescript file changes in the following:

https://public-001.gitsense.com/insights/github/repos?q=lang...

you can see the patterns are much more consistent. Based on these wild swings, I really don't know how GitPrime and similar solutions are not generating metrics with big banners that says "these numbers may not be very useful".

In the business world, business intelligence is widely accepted and management fully understands that you still have to work at it, to get meaningful insights from BI and I'm hoping this attitude is adopted for developer insights.

I'm still early in my research, but I believe the metrics that both management and developers can get behind are impact based metrics. Impact really can't tell you if somebody is more productive than another person, it just says they are having a greater impact to the code base.

For example, with impact analysis, you can quickly identify busfactor that can tell management, if this developer leaves, we are probably going to experience delays in development. Impact analysis will also make it easier for developers to fight for raises as they will be better able to tell leaders how they are having an impact, compared to say a colleague. Impact analysis will also tell you if a developer is not stepping out of their comfort zone or confirm that you are not giving them a chance to expand, and so forth.

I personally think, trying to optimize developers for speed is a loss cause, and we should be focusing on metrics that can help reduce project risk, which I think everybody can get behind.

So, is this metric actually used by some organization?

Sounds good to me but there is no statistics nor review from other developers/managers trying the metric...

To paraphrase:

Every team, every project, every individual is different, and may need productivity measured in different ways. We've captured a bunch of different ways to measure into several paragraphs, and think you should use this information to capture all those different measures of productivity while accounting for each unique circumstance you have.

In my opinion:

OK, I'm not management. I'm a developer who wants to "get in flow" and be productive. To contribute while improving my skills. Some of us are "engineers" in mindset, that is, we seek efficiency and optimization. Humans are, of course, notoriously difficult to optimize for. As a team with a project, you should have meaningful goals - this project saves time/money, reduces mistakes/friction/churn, uses up valuable resources in less quantity than the other valuable resources it ends up generating. At some level you want to dig in and optimize; that is, make sure your team has the clarity, tools and ideally, motivation to accomplish the goals you set for your project. And as human resources manager, you might see developers as tiny ROI projects where you want to pinpoint how much Return that particular Investment is giving you. It's at this point that I might say "good luck." I mean, yes, having bad members on a team isn't great, so don't throw your hands in the air and do nothing.

On a sufficiently small team, where leadership understands enough about the work being done (productivity) and how the team works together and contributes, shouldn't it be reasonably apparent who is and who is not a solid contributor? As an individual contributor, I usually believe I end up with a pretty insightful view into who contributes well, and who blows smoke at each meeting while contributing poorly.

Of course, at small organizations, no one dares promote me beyond my level of competence, because my contributions are too valuable. At a larger organization, I would likely be promoted, and maybe for a brief moment, I'd retain my grasp on the contributions of the team I manage, but before long, I'd be swept away into an endless stream of meetings with basically everyone except my team, and I'd have lost my ability to see into that world quite so well. I'd start to hate it and only seek higher titles and compensation but I'd have lost the will to meaningfully contribute.

If I have any point in this, I think teams succeed when individuals succeed, and that happens when you remember they are humans, they want to succeed, and if you listen to their requests, make sure they know what they need to and are not resource-restrained to the point of being unable to succeed, they will probably be happy to contribute. You can always have bad seeds, but going into it with a mindset of measuring, managing and optimizing humans is probably setting yourself up for failure.