Hacker News new | ask | show | jobs
by ludovicianul 1180 days ago
On a tangential note I've also asked here (https://news.ycombinator.com/item?id=35245329) what will be some performance indicators to take into consideration when delivering software. That '50 PRs in 6 months' is interesting. You might argue that "it's important to deliver business value" and "as long as your hitting your market/business capabilities targets" everyone is happy. But my question is still: "how do you know you are being efficient? can you still deliver with half the number of people?".
1 comments
oa335 1180 days ago
A favorite “tactic” of some developers Ive seen is to deliver a half baked solution quickly, then a continuous stream of fixes to that solution. An easy recipe for creating merging a lot of PRs.
link
tmountain 1180 days ago
In general (and not just in software), anything that becomes a known productivity metric will rapidly converge towards the mean.

The worst example I have seen is incentivized story points. Bad news: you just ruined your estimation process.

Managers end up trying to put in counter measures and the whole thing becomes a convoluted mess.

Personally, I think PR are a decent metric, but you need an engineering manager to review (and understand) the work that the team is doing (and the team dynamics—who’s doing what).

Basically, the only way to really understand productivity is to be close to the team. This takes time, and it requires hiring the right manager, so a lot of companies opt for off the shelf solutions (Pluralsight, Jellyfish, etc).

Not saying this is good or bad, it’s just what I have observed.

link
ludovicianul 1180 days ago
Agree. This is why "measuring" is bad. You want to monitor. To proactively see how things are going on and consider the context around it.
link
ludovicianul 1180 days ago
I totally agree. This is why is bad to "measure". When you say measure, everything will look right in the end. But if you say "monitor", at least to me it feels more towards: "I'm proactively looking at my team to see how it goes. I have a way to see when things will start to go wrong. I can also see how productive people are by correlating data. If I just take PRs as an isolated number, it's not relevant. But if I take it, and see that 80% are actually bug fixes, that raises an issue in itself"
link