These smell like the kind of metrics that cause someone to feel informed and then to miss the forest for the trees. The kind of data for a "data driven" decision maker who will just invent a narrative to explain the numbers, and then do what they wanted to do all along.
The map is not the territory.
palmotea•28m ago
> These smell like the kind of metrics that cause someone to feel informed and then to miss the forest for the trees. The kind of data for a "data driven" decision maker who will just invent a narrative to explain the numbers, and then do what they wanted to do all along.
> We need to increase reliability in the kernel, so the kernel team should fire the top 5 bug-introducers, to reduce the amount of bugs being introduced (https://pebblebed.com/blog/kernel-bugs-part2/05_author_analy...). Linus has got to go.
You've cut bugs being introduced while also reducing development costs by slashing team size. You deserve a promotion and an increase in equity.
alwa•19m ago
The LLM-tone doesn’t help:
117 people meet this criteria. And the impact is dramatic:
It’s strange to me to think of “bugfixes” in terms of a commodity. Different problem spaces between subsystems and thus different types of (and surfaces for) bugs; different contributor mixes; different number of eyes on them; different potential impacts…
> CAN bus drivers top the list [of bug lifetime by subsystem]. These are used in automotive and industrial systems. Critical infrastructure with few maintainers watching.
…or maybe higher-quality initial submissions, with most of the easy bugs already wrung out of them, so only subtle bugs remaining (thus fewer to fix). Or adequately vigilant maintainers but low diversity of systems running that code, thus fewer users/situations where the bugs manifest, so they go unreported. Or poorer telemetry so an ordinary rate of latent bugs but they go undetected. Could be any, probably a little of all, can’t really tell from the analysis; and each cause would suggest a different response to improve quality.
jeffbee•21m ago
Bugs Georg, who is an outlier and should be excluded from the analysis.
petterroea•13m ago
Not happy with the lack of statistical testing, some of the smaller differences in % could probably be coincidence
dogleash•45m ago
The map is not the territory.
palmotea•28m ago
We need to increase reliability in the kernel, so the kernel team should fire the top 5 bug-introducers, to reduce the amount of bugs being introduced (https://pebblebed.com/blog/kernel-bugs-part2/05_author_analy...). Linus has got to go.
gchamonlive•13m ago
You've cut bugs being introduced while also reducing development costs by slashing team size. You deserve a promotion and an increase in equity.
alwa•19m ago
117 people meet this criteria. And the impact is dramatic:
It’s strange to me to think of “bugfixes” in terms of a commodity. Different problem spaces between subsystems and thus different types of (and surfaces for) bugs; different contributor mixes; different number of eyes on them; different potential impacts…
> CAN bus drivers top the list [of bug lifetime by subsystem]. These are used in automotive and industrial systems. Critical infrastructure with few maintainers watching.
…or maybe higher-quality initial submissions, with most of the easy bugs already wrung out of them, so only subtle bugs remaining (thus fewer to fix). Or adequately vigilant maintainers but low diversity of systems running that code, thus fewer users/situations where the bugs manifest, so they go unreported. Or poorer telemetry so an ordinary rate of latent bugs but they go undetected. Could be any, probably a little of all, can’t really tell from the analysis; and each cause would suggest a different response to improve quality.