Engineering productivity can be measured, just not how you'd expect

Re:Engineering productivity can be measured, just not how yo... by majormajor on Tuesday February 02, 2021 @07:42PM (#26009192)

> Based on what I've observed by studying successful open source projects, you actually want to discourage "very high impact" employees, since they introduce knowledge risk.

This is a dangerous conclusion, especially for a business. If you're in pure maintenance mode, maybe... but otherwise... You want people who can pitch in anywhere, who can fix things rapidly, who can build new solutions quickly when required, and who know your business inside and out.

You just don't want knowledge siloed there, so you want to make sure other people are also on the path to being expert on the various areas.

[ Parent | on HN ]

Re:Engineering productivity can be measured, just not how yo... by sdesol on Tuesday February 02, 2021 @08:05PM (#26009364)

Context obviously matters and I think it is important to understand what I mean by "Very High" and "High" impact employees. High impact employees can still do everything by my definition, it's just that they aren't doing everything. Obviously some business/projects do not have the luxury of attracting lots of talented employees, so "Very High" impact employees are inevitable.

If you look at the busfactor stats in the deep dive section

https://imgur.com/tiGFmFf

The number of files that are being changed with only one author is 419 (or about 25% of all the files changed in the 90 days window). So 75% of the files changed in the 90 days window have two or more contributors, so I think those working on the vscode project aren't being siloed (based on my quick observations).

[ Parent | on HN ]