Live data from Hacker News

Can developer productivity be measured?

stackoverflow.blog

111–120 of 159 posts

Re: Can developer productivity be measured?

#111
post #52

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriousl…

Eventually any simply metric like this will become warped because of the effects of both Goodhart's Law, and Campbell's Law.

Something that I've been wondering about is that maybe team's should decide what their metrics are for the upcoming 3 months and then come back and decide what the new metrics are. At the very least, it becomes a big game about the org then.

Impossible to have 'metric based reviews' at that point. But I think that's fine.

Re: Can developer productivity be measured?

#112
I don't get orgs that use stats like commits/LoC/PRs as KPIs. Most time for software engineering ought to spent ensuring you're building the right thing which requires a lot of collaboration, writing design docs, thinking about the problem, etc to avoid 'building the wrong thing' which is probably the 'default' behavior and hard to avoid. Software engineering is only really valuable if you can easily extend and build it on it to enable whatever product or service you're selling to change as the business changes. If you're churning out throw-away code you never reuse you don't realize any of that value and you will lose.

I did have the idea of directly tying value to a graph of code that enabled a certain user journey. Sorta like 'CUJ-coverage' instead of test coverage. So if a user spent $20 at checkout, every line of code that was touched to enable that user's journey would be credited with that $20. I think this would be an interesting metric I'd probably respect but there are still probably a lot of blindspots this methodology doesn't capture.

Re: Can developer productivity be measured?

#113
In my ~25 years of professional software development, the single biggest factor in productivity for me has been whether I was involved at the start of a project. Knowing the initial design decisions, and being comfortable changing anything, allows me to be orders of magnitude more productive than when I'm diving into existing code designed by someone else.

I saw this perhaps most acutely with a company I sold - for a couple of years I was more productive than on nearly any other large software project I've worked on, because I knew the ins and outs of everything. The developers who bought it and took over are probably better developers than I am, and they are unquestionably excellent coders, yet it took a couple of years for them to get productive at making even medium sized changes. It became incredibly obvious to me how handicapped you are diving into something someone else made, especially if the original designer isn't there anymore.

Meshing really well with managers & PMs is probably the next biggest factor in my own experience, but it doesn't come even close to the gap between being there from day 1 vs coming in much later.

> Productivity tracking tools and incentive programs will never have as great an impact as a positive culture in the workplace.

I'm a fan of choosing to use time management apps and productivity tools to manage my own budgets. But I admit that I hate it when I have to do it for someone else.

Re: Can developer productivity be measured?

#114

love the classic 'are story points hours / no / then wtf are they' conversation when PMs intro jira + cousins have never been sure how summing together something that is supposed to have no relationship with time magically provides an estimate of anything also not sure why teams are using the central source of truth for progress as the 'daily todo list making' tool I live in the real world so I estimate in hours

The answer is in the article itself. It gives you real historical data so you can predict how long the project will take with evidence, rather than just a feeling, hope, or guess. > Velocity is an aggregate measure of tasks completed by a team over time, usually taking into account developers’ own estimates of the relative complexity of each task. It answers questions like, “how much work can this team do in the next…

hmm fair, I skimmed and should have read more carefully

still: (1) sounds like complexity predicts weeks? so they are estimating hours. And (2) I think if jira clones were really a tool for estimation, they'd have uncertainty scores and some kind of prediction market built in

Re: Can developer productivity be measured?

#115
post #101

Earlier quoted context omitted.

Your proposed law has been tried for many years, by just as many good-willed people who believed their measures would result in target increases. In fact, the entire industry is being bombarded by one such methodology that includes those measures: Scrum. Must we really repeat the years of complaints, criticism and debates to show any measure can get warped and gamed to the point it only vaguely resembles a tool of pr…

> how do you encourage them to tackle bigger technical problems? Those that lay the foundation for the new people to do their job more easily and on-board quicker? Isn't gitlab known for disastrously poor infrastructure with all the long outages? I.e. the exact things where people need to take their time to tackle bigger technical problems, not complete short tasks. I guess this attitude explains it, at least partial…

Would be sure nice to back up those claims.

Re: Can developer productivity be measured?

#116
post #104

Earlier quoted context omitted.

Not making mistakes isn't productivity, that's the bare minimum of acceptable behavior.

People aren't perfect. Mistakes abound. If the bare minimum for a position was "no mistakes" you'd never find a qualified candidate. I'll go further and add that your attitude makes things worse in practice because since mistake can, and do happen, your wholesale rejection incentivizes effort spent hiding mistakes and scapegoating. That's effort that could have gone into getting useful work done.

I’d go even further and say there are two types of programmers:

1. The ones that “don’t make mistakes”, but actually they are just unaware. 2. The ones that expect themselves to make mistakes and prepare for that.

Re: Can developer productivity be measured?

#117

love the classic 'are story points hours / no / then wtf are they' conversation when PMs intro jira + cousins have never been sure how summing together something that is supposed to have no relationship with time magically provides an estimate of anything also not sure why teams are using the central source of truth for progress as the 'daily todo list making' tool I live in the real world so I estimate in hours

The answer is in the article itself. It gives you real historical data so you can predict how long the project will take with evidence, rather than just a feeling, hope, or guess. > Velocity is an aggregate measure of tasks completed by a team over time, usually taking into account developers’ own estimates of the relative complexity of each task. It answers questions like, “how much work can this team do in the next…

A clear solution for this exists: we should double the number of people who are estimating how long a project will take.

Re: Can developer productivity be measured?

#118

Maybe when developer productivity measurment becomes standard accross the industry we will realise that tech workers are in fact workers. Cogs in a machine. And not independant individuals imposing their will to the world through sheer will like some Randian hero. Maybe then it will then be plainly evident that developers are as alienated as any service worker, and in the end as disposable in the eyes of the sharehol…

> as disposable in the eyes of the shareholders. If a company is willing to sacrifice engineering talent and institutional knowledge for short term gains... Good luck staying in business. Reference: Every outsourcing project I've seen.

They are called Best cost countries now.

Re: Can developer productivity be measured?

#119
post #63

What is productivity of managers? How it is measured? Why productivity of developers must be measured, but productivity of managers not?

For better or for worse, manager's productivity is normally taken from the developers/engineers the manager manages, namely the team's overall productivity, so we're back to the same problem of how to measure developer's productivity

My productivity (as a manager) is measured by my ability to deliver on commitments I make with product management and senior leadership. Basically, my ability to match my teams' productivity with corporate goals.

Which lines up with nradov's comment about the smallest useful unit for measuring productivity is the typical self-contained development team. Attempting to determine if Bob in TeamA is more productive than Cindy on TeamB doesn't generally result in any actionable information. What matters (from a senior leadership perspective) is can TeamA or TeamB build the things that need to be built in a timeframe that's acceptable to stakeholders.

As a manager, if I feel like Bob or Cindy are unproductive, then I need to figure out why. And LoC or number of commits isn't going to tell me that. Possibly the number of defects found in QA, but even that isn't perfect.

Re: Can developer productivity be measured?

#120

Earlier quoted context omitted.

> hiring someone better at double the pay Well... if you knew how to spot somebody twice as good as the one you have now, why didn't you hire that guy in the first place?

Because he demanded twice the salary?

Well, in that case, I’m 10 times as good.
Post reply on HN