Software Engineering at Google Chapter #7 - Measuring Engineering Productivity (2 of 3)

  • Reasons NOT to measure things:
    • The results will be invalidated by other factors
    • Example: Measuring software development speed before a major re-org
    • Know your audience. Some people have ideas or biases based on past experience and no amount of persuasion will change their mind. Some prefer qualitative, some prefer quantitative
    • The only available metrics are not precise enough to measure the problem and may be confounded by additional factors
    • Don’t settle for a less precise metric or proxy metric
    • Either way, it’s not a good approach as it’s lack of precision may incorrectly confirm beliefs
    • Don’t use the results as vanity metrics or as confirmation of an action you planned to take regardless
    • In these cases, the definition of success is getting the stakeholder the data they need in order to help make the best decision
  • LOC is a terrible metric because it encourages “insipid code”. See them as “lines spent” vs “lines written”
  • To create a metric use the GSM framework as follows:
    • Goal - End result phrases in terms of what you want to understand at a high level. Should not contain specifics.
    • Signal - How you know you have achieved the end result. Unmeasurable.
    • Metric - The thing we can actually measure, the proxy for the signal
    • Each goal should have 1 or more signals associated with it
    • Each signal may have multiple metrics associated with it
    • GSM forces users to think about which metrics help us reach our goals vs which metrics are available. There are more options. Always.
    • When using GSM you must maintain traceability so you can follow the metric back to the signal
  • The streetlight effect: You have lost your keys and are only looking for them under the streetlight because that’s the only illuminated area. You can look elsewhere, too.



Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.