
Software Engineering Metrics Every IT Project Manager Should Consider - alesdonoso
https://blog.scope.ink/4-software-engineering-metrics-every-it-project-manager-should-consider/
======
Traster
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.

------
ajarmst
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.

------
lovich
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

~~~
alesdonoso
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!

------
m0zg
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.

------
royosherove
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](https://www.youtube.com/watch?v=goihWvyqRow)

~~~
alesdonoso
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 :)

------
aliswe
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

------
mrits
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.

~~~
zzzcpan
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.

