The only way to do it I can think of: have two teams or individuals develop the same thing simultaneously and measure the time required to get a result of the same quality. This should be done in longer term to take into account code quality (poor code quality slows down future development).
Can developer productivity be measured?
61–70 of 159 posts
Re: Can developer productivity be measured?
#62Any decently competent technical leader can tell if a developer is being productive or not. It's stupid to waste time trying to measure something that is virtually unmeasurable.
[deleted]
Re: Can developer productivity be measured?
#63What is productivity of managers? How it is measured?
Why productivity of developers must be measured, but productivity of managers not?
Re: Can developer productivity be measured?
#64He mentions increasing salary won't lead to increased productivity ... and that's true, if the same developer remains. But what if we remove that constraint? What if increased salary means a higher quality of developer takes the position? Wouldn't this mean higher productivity? Bit of a cold scenario, but one way to game it out is hypothetically removing the current dev and then hiring someone better at double the pa…
He's right and wrong at the same time.
If I pay above market rate I'll attract better devs for sure, and the caliber of folks in my hiring pipeline will get better. It's not obvious at all unless you know where to look. College is the prime example of that. If you pay better you'll have more new grads applying and they will prioritize you over other offers (unless you are an exceptionally prestigious employer). But even then, you'll never talk to the student who interned twice at FAANG and got a firm offer a year before graduation. You can get that guy only if you are willing to employ him at FAANG salary for two summers.
Employing these guys won't make my existing hires any better than they are in the immediate future.
However
Better hires leads to better teams. I find that certain developers have a multiplicative effect that applies to other devs. They mentor, document, review and help everyone grow. That might actually slow them (taking half a day to explain high level architecture to a lowly junior coder) until you realize the junior coder is now capable of answering questions from his teammates.
Re: Can developer productivity be measured?
#65What 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
Re: Can developer productivity be measured?
#66Maybe 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.
Re: Can developer productivity be measured?
#67Most software projects get managed with a ticketing system that logs the work to be done as individual tickets. Counting the number of cards a developer closes over a certain period allows us to see what actual work is getting closed off. Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority. When more tickets get closed, more good things are happening w…
> Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority
Don't forget the weight.
I've seen single tickets taking weeks for bug investigation.
Re: Can developer productivity be measured?
#68Productivity 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…
The most common implementation I've seen of this are senior developers who write almost no code, but spend their time telling junior developers what to go back and reimplement, giving advice, etc. It's still the junior programmer's actually getting the product written, just with nudges in the right direction. Not a bad system really, reminds me of the relationship between officers and enlisted in the military.
Re: Can developer productivity be measured?
#69One of the most useful programmer metrics that I've found is code churn: (new lines + deleted lines) / total changed lines. Instead of telling you how much work your programmers are doing, this metric tells you what kind of work your programmers are doing. Small numbers mean bug fixing (end of project and maintenance) and large numbers mean new development and features.
What about high deletion amounts? I've merged PRs with hundreds of thousands of lines deleted and none added. It took quite a bit of sleuthing to figure out someone had left entire copies of directories side by side with different names, where one was completely unused. Conversely, someone had a huge addition to the repo that actually was total garbage.
Re: Can developer productivity be measured?
#70The only way to do it I can think of: have two teams or individuals develop the same thing simultaneously and measure the time required to get a result of the same quality. This should be done in longer term to take into account code quality (poor code quality slows down future development).
A few things can play havoc with this type of measurement. One is that the way we determine the "quality" of the code is based on the current scope of the project.
If the scope right now is pull a bunch of values out of spreadsheets and generate reports on them, the highest quality code would be the most terse: it looks up the files, get the information, then displays it. If tomorrow the scope changes to "do that, but in realtime, across multiple machines", the highest quality code is the one that implemented a database and REST API.
Since scope changes all the time, we can never evaluate which set of code is the highest quality.