Software Engineering Metrics Every IT Project Manager Should Consider

All of these metrics seem to be a poor substitute for building a team where you can trust your team to be honest about how they're progressing, where their blockers are and what technical challenges they see coming. If the way you're finding out a team member is stuck on something is the number of commits they've made in the last week then you aren't paying enough attention. More likely they're writing documentation, or researching, or just are working on a big change that they'll commit tomorrow or maybe they're simply babysitting the intern. Instead of actually knowing what you're team is working on, you've just created a new metric that doesn't really mean anything and is going to throw up false positives that you can spend your time chasing.

I mean, let's take impact. Can we measure the real Impact of a change? No. We're measuring a relatively bad proxy - connectedness. Is the change highly connected to all the other code. Is that something we want to encourage? Not really, if you're optimizing for impact you're creating a situation where your developers are going to write tightly coupled code. It's not good to create that artificial incentive. Okay, so maybe we want the opposite - low impact. Who exactly thinks aiming to be low impact is a good idea?

You could almost rephrase the subtitle as:

>Lines of code have almost no importance while other metrics of no importance are becoming more popular nowadays.

Whenever a manager proposes a metric, they should be required to preface it with an explanation of Campbell's Law and why they believe it wouldn't apply in this case.

I thought this was a submarine article from Gitprime for a second as they use the exact same measures.

I find the metrics useful for managing my devs, but only as a secondary set of measures. If a team is hitting their goals for the project, I never need to look at these measures. If the team isn't hitting their goals I need to dive in deeper and these stats help me determine if the problem is the engineers just aren't working, or if its an issue outside of their control.

Its also been a good piece of ammo to help train non technical upper management into accepting work from home more. I can show them directly how much the engineers are working and they lose that fear that people are just shirking their duties when they work from home

It's fine to "consider" these so as long as they do not impact the performance review process. Because if they do impact it, people are going to game them, and they'll become exceedingly efficient at it. Want more PRs? You'll see dozens of PRs a day. Want more reviews? Get ready for bullshit PRs "reviewed" by the dozen. Want more LOCs? Get ready for massive vertical whitespace and detached curly braces.

But really, as a (former) manager this is trying to solve a problem that does not exist. As a manager I'm intimately aware who my most productive reports are. I know what they do, what they worked on last week (I monitor their PRs), when they work, how much bandwidth they currently have, whether they need to take a bit of a break after a tough string of PRs and work on something fun, whether they're stuck and need to be redirected to something else, etc, etc. I call this "management". Managers should actually try to do their jobs. There's never any ambiguity about who sucks and who doesn't, and you can try to bullshit me, and it might even _appear_ to you that your BS works, but in the end I know who's who.

What's really missing from the IT world is a good understanding of leading vs lagging indicators (metrics) - which would help remove many of the anti patterns we know are bad, but can't explain why. I talked about it in this at GOTO last year: https://www.youtube.com/watch?v=goihWvyqRow

I either question or don't understand this.

> Code Churn is the percentage of the code workflow of an engineer. It normally means the frequency of lines added and deleted in every commit. Measuring the churn, managers are able to control the software development process, fundamentally indicating the quality of the process of each engineer. The spikes normally represent that something is not going as normal as it should be.

The whole article doesn't really feel that agile? I dunno

I have issues around code churn as a useful metric with your definition. Large Added/Deleted lines could just as likely be signs of a productive team.