Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So, wrt the article, by my estimate the quantifiable criteria you listed are:

* Fixes bugs/regressions quickly (time spent)

* Creates test plans (number of plans created)

* Helps with recruiting (number of candidates interviewed)

* Keeps issues up-to-date with progress (number of issues updated)

* Helps guide other merge requests to completion (number of merges)

* Provides thorough and timely code feedback for peers (time between commit and feedback)

Just curious if you track any these metrics or if this is mostly a "qualitative" feeling of how the developer is performing?



Here is the incentive system you're advocating.

>Fixes bugs/regressions quickly (time spent)

Do the least possible to make it work again, don't investigate or fix the underlying confusion or low-quality subsystem that made it break. Volunteer for bug fix tasks that look easy, stay away from the ones that look hard.

>Creates test plans (number of plans created)

Write low-effort test plans.

>Helps with recruiting (number of candidates interviewed)

Give lots of interviews without really paying attention.

>Helps guide other merge requests to completion (number of merges)

Get your friends to split all their changes into the smallest possible merge requests so you can accept as many as possible.

>Provides thorough and timely code feedback for peers (time between commit and feedback)

Provide rapid but low-effort feedback.

Metrics-driven management is cancer and you should run, not walk, from any organization that expresses any inkling of interest in it.

You (in general, not parent specifically) are almost certainly not smart enough to create an quantitative incentive system that actually produces the behavior you want, rather than the appearance of it. Respect the difficulty of the task, and don't.


This exactly nails the point in the article about checklists and how you can't really create effective quantitative metrics for developers.


I have read in the past about developers using various quantitative measures (number of commits, for example) to measure their own work. I think in that scenario it's different because the extrinsic reward is driven by intrinsic motivation -- you're unlikely to try and game your own metrics I suppose?


> you're unlikely to try and game your own metrics I suppose?

You'd be surprised.


Makes perfect sense, actually. Well said.

[edit] I will add that much of the responses to the metrics are quite cynical -- assuming people will game the metrics. Therefore, I agree.


Some people will consciously game the metrics and some people will unconsciously game the metrics. Some people might not game them at all, but if a chunk of the team is gaming them, then its already game over.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: