Software Engineering Metrics Every IT Project Manager Should Consider
1–10 of 12 posts
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#2I 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.
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#3I 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.
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.
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#4What'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
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#5Whenever 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.
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#6I 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
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#7It'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.
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#8I 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…
Hi there lovich and thanks you for your reply!
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!
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#9What'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?
Thanks for reply :)
Re: Software Engineering Metrics Every IT Project Manager Should Consider
#10I 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.
Hi mrits! thanks your for your reply :)
That'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.