Org Structure predicts Code Quality

Not sure where I found this (LMK if you shared it recently so I can credit you!), but Microsoft published a paper back in 2008 where they studied the launch of the Vista operating system and checked to see how "traditional" predictors of code quality compared to organizational metrics.

Traditional measures

1. Code churn: code that changes a lot is more likely to be buggy
2. Code complexity: code that is more complex is more likely to be buggy
3. Pre-release bugs: bugs before launch predict bugs after launch
4. Dependencies: code that relies on other code is more likely to be buggy
5. Code coverage: code that is untested is more likely to be buggy

Organizational measures

1. Number of engineers: How many people people touched the code?
2. Number of ex-engineers: How many people who touched the code, and then left the company?
3. Edit frequency: What was the total number of times the code was edited? (seems pretty similar to code churn)
4. Depth of master ownership: How far down the organization is the owner of the code?
5. Number of orgs contributing: How many different (internal) organizations touched the code?
6. Percent of all engineers that contribute: How many engineers, out of the total number of engineers in the company, touched the code?
7. Percent of owning org that contributes: How much did the engineers in the "owning org" contribute to the code, compared to everyone else?

Turns out the organizational measures were better predictors of code quality than the traditional ones.

Which makes sense, especially if you've read the Team Diagnostics research by Ruth Wageman, J. Richard Hackman, and Erin Lehman.

They studied thousands of teams, and determined that there is a predictive relationship between six teaming conditions and the outcomes that the team is able to create. Better conditions, better outcomes.

Research says that you don't need to work harder. You don't need to create a new process. Improvements in these areas don't predict improvements in outcomes.

Instead, you just need to work on creating a real team, with the right people, and a compelling purpose. If you add good surrounding structure, supportive organizational context, and give the team coaching...that's even better, but not a requirement.

And if we overlay Microsoft's Organizational measures with the six team conditions...it makes sense why team stuff beats approach stuff when it comes to predicting team outcomes.