No issues with other metrics? To me all those metrics look like they are targeting work where every problem is well understood and people are just implementing primitive solutions and fix bugs. Or maybe just maintenance work. But not work where something new is created, actual problems solved or even just some amount of creativity involved, because then all the metrics will look abnormal and unpredictable.
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
Hi royosherove! Very interesting GOTO! I think these metrics you are talking about are really interesting.
At minute 30:13 you talk about those indicators and put some examples at the blackboard, I find most of them very interesting but for "Critical Security Issues" I'm really wondering how can you differentiate between PRs that are fixing things that PRs that are just implementing new features?
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
You might be right since too many it managers work with OKRs so they don't need as a the first instance tool a git analytics one. In your case, it makes sense to have a tool like Scope "as a secondary set of measures" if everything is going well in your company! That's the point overall :)
However, our tool involves engineers "gamifying" their processes so what we get is more motivated engineers, better team communication, company climate and culture.
For managers, all data behind SCMs could be easily tracked so we make life easier! For non-tech profiles and remote teammates asking for metrics, it's worth also!
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.
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.
> 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
11 comments
[ 0.30 ms ] story [ 38.3 ms ] threadThat's true. The point w/ Code Churn is to have an approximation to know when there has been more flow of changes in a specific repository.
At minute 30:13 you talk about those indicators and put some examples at the blackboard, I find most of them very interesting but for "Critical Security Issues" I'm really wondering how can you differentiate between PRs that are fixing things that PRs that are just implementing new features?
Thanks for reply :)
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
You might be right since too many it managers work with OKRs so they don't need as a the first instance tool a git analytics one. In your case, it makes sense to have a tool like Scope "as a secondary set of measures" if everything is going well in your company! That's the point overall :)
However, our tool involves engineers "gamifying" their processes so what we get is more motivated engineers, better team communication, company climate and culture.
For managers, all data behind SCMs could be easily tracked so we make life easier! For non-tech profiles and remote teammates asking for metrics, it's worth also!
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.
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.
> 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