4 ms·

What's a horrible metric to measure a software developer's performance?

• marcodiego 6y ago
  Very bad metric: number of lines of code. It basically values unwieldy code.
  • JMTQp8lwXL 6y ago
    If in the frontend stack, just install/upgrade/remove a few dependencies. Huge LoC change count due to new dependency tree being reflected in your npm or yarn lockfile.
• nickm12 6y ago
  Pretty much all of them. In addition to story points and lines of code, developers have been measured based on tickets closed, tests written, code reviews sent and received, revisions per code review, and so on. None of these should be used as a naïve input to performance evaluation for software developers. However, that isn't to say that they aren't useful for evaluating performance. One way they can be useful is to compare peers, look for outliers, and try to understand what is really going on. Often times these are just going to be noise that are specific to the project or system they work on and not the quality of work. But sometimes these quantitative metrics and help identify interesting patterns. For example, maybe a dev is an outlier in number of code review comments because they are a time-wasting nitpicker, or maybe because they are using code reviews as a tool to mentor junior engineers. I think when used this way, these quantitative metrics can be a way to highlight areas of particular strength or weakness that the manager might not realize if they are just going on what they see incidentally. You have to trust the manager, or whoever is doing the performance evaluation, to use these tools for good and not evil.
• musicale 6y ago
  Any and all of them, though I particularly dislike: - time spent sitting in an office chair or typing at a keyboard - availability to work and/or respond to email/slack/etc. after hours - enthusiasm for sacrificing one's personal time, health, sanity, and family/social life for the benefit of the company - anything related to source code or issue changes - number of meetings (especially standup meetings) attended - number of slack posts or email messages sent or received - effectiveness at artificially inflating the boss' ego etc.
• badinsie 6y ago
  our velocity is never accurate. 2 week sprints with a bunch of groomed stories planed by business. cool, well... we're also spending hours a day on operation related incidence. we have code reviews. training. peer mentoring. so many meetings. i had to spend hours with a new jr dev last week trying to connect to our VPN and just basic windows stuff.... i was out of pocket for 3 hours yesterday because of force updates to my laptop. meanwhile i was supposed to be pushing a deploy to production... my internet went out for a few hours today because centurylink is just a POS. hmmm. a few weeks ago my roommate forgot to pay the electric bill and our power was out for half the day. life happens. family happens. shit kinda just happens ya know...
• superbcarrot 6y ago
  > When a measure becomes a target, it ceases to be a good measure. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
  • eecks 6y ago
    I just posted the same - looks like you got there first :) I have seen this play out many times.
• smlckz 6y ago
  I don't know if it is good or bad, but, think about the following metric: the number of lines written but eventually deleted divided by the number of lines of code retained.[1] [2] [1]: http://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/ http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro... [2]: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
• p0d 6y ago
  The length of their beard.
• eecks 6y ago
  The problem is when something is measured it normally becomes a target and: Goodhart's Law: When a measure becomes a target, it ceases to be a good measure
• mod 6y ago
  Typing speed
• karmakaze 6y ago
  I don't believe in metrics for individuals. I do believe in metrics for a team, made by the team, and used by the team. The best metric we had when I was on a platform team was hours spent firefighting per sprint. These didn't have to be burning production issues, just ones that we're unplanned and couldn't wait to be dealt with. We scheduled time each sprint for firefighting and we would estimate higher or lower depending on our confidence in the stability/performance expected from recent developments both internal and external. It was the most satisfying thing to see this number start ridiculously big when we added up all the time spread between team members and fall an order of magnitude and also interrupt fewer members to let them focus. If there was a metric, it would be an inverse: number of times per day checking email, slack, refreshing whatever page, popping into HN.
• gitgud 6y ago
  Lines of code, files touched, bugs fixed, hours worked. Basically any quantifiable metric. There's a couple of reasons why it doesn't work. Metrics either try to encapsulate too much or too little scope. For example; is having more lines of code per week a good thing, well only if the lines of code are meaningful, how do you measure that? And that would encourage verbosity over simplicity. Another issue is that it's almost impossible to stop engineers pleasing the metrics, rather than solving the problem. If their job or bonus depends on a metric, then that metric becomes a higher priority than the actual job. It's also incredibly hard to quantify contributions to an evolving project. Writing software might be compared to building a house from a design, where someone is paid for precisely how many bricks they lay. But software development has transitioned away from the waterfall design, to a more iterative approach. This means huge amounts of effort put into the product, might be designed out through iteration and changing business requirements. So if you were to pay people based on the end product (like brick layers), some people may receive nothing. Basically, there's no way to fairly attribute the success of the system to individual programmers. Good software is written by teams and good teams are comprised of different people with different skill sets.