Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering productivity can be measured, just not how you'd expect

okayhq.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: Engineering productivity can be measured, just not how you'd expect

#41

Post by majormajor »

sdesol wrote: post #40
necco908 wrote: post #34

Measuring engineering can be a slippery slope towards stack ranking performance -- which ultimately hurts performance and culture. I think you have to measure with the intent to improve how your team works. If a manager can measure at the team level and open up visibility into the development process, they can hopefully find where things get frustrating (ex. waiting for someone to review a PR). That said, there seem…

I'm currently working on a solution that will try to quantify software development health, and what I've learned from analyzing thousands of popular open source projects, is you don't want a single individual to stand out. You want work to be fairly distributed to reduce knowledge risk. If you look at the busfactor section for the vscode and gitlab repository https://imgur.com/NfgvvTy (vscode) https://imgur.com/DK7rv…

> Based on what I've observed by studying successful open source projects, you actually want to discourage "very high impact" employees, since they introduce knowledge risk.

This is a dangerous conclusion, especially for a business. If you're in pure maintenance mode, maybe... but otherwise... You want people who can pitch in anywhere, who can fix things rapidly, who can build new solutions quickly when required, and who know your business inside and out.

You just don't want knowledge siloed there, so you want to make sure other people are also on the path to being expert on the various areas.

Re: Engineering productivity can be measured, just not how you'd expect

#42

Post by sdesol »

majormajor wrote: post #41
sdesol wrote: post #40

Earlier quoted context omitted.

I'm currently working on a solution that will try to quantify software development health, and what I've learned from analyzing thousands of popular open source projects, is you don't want a single individual to stand out. You want work to be fairly distributed to reduce knowledge risk. If you look at the busfactor section for the vscode and gitlab repository https://imgur.com/NfgvvTy (vscode) https://imgur.com/DK7rv…

> Based on what I've observed by studying successful open source projects, you actually want to discourage "very high impact" employees, since they introduce knowledge risk. This is a dangerous conclusion, especially for a business. If you're in pure maintenance mode, maybe... but otherwise... You want people who can pitch in anywhere, who can fix things rapidly, who can build new solutions quickly when required, and…

Context obviously matters and I think it is important to understand what I mean by "Very High" and "High" impact employees. High impact employees can still do everything by my definition, it's just that they aren't doing everything. Obviously some business/projects do not have the luxury of attracting lots of talented employees, so "Very High" impact employees are inevitable.

If you look at the busfactor stats in the deep dive section

https://imgur.com/tiGFmFf

The number of files that are being changed with only one author is 419 (or about 25% of all the files changed in the 90 days window). So 75% of the files changed in the 90 days window have two or more contributors, so I think those working on the vscode project aren't being siloed (based on my quick observations).

Re: Engineering productivity can be measured, just not how you'd expect

#43

Post by groby_b »

cccc4all wrote: post #32

The process of abstracting away people into units of productivity is common approach to Software Engineering management. It has failed every time. When the latest management fad fails to live up to expectations, new terminology are created to hide the failed management fad. New terminology simply replaces the old terminology and they can now sell new and improved management concepts again and again. Software Engineer…

Productive software engineers aren't "exceptional". If you focus on removing obstacles, you can make most software engineers productive.

The point is learning from those who've succeeded before you, instead of claiming it's just magical chemistry happening. Or worse, starting again from first principles.

No, that won't produce product-market fit, nor does it open up once in a lifetime opportunities, but it allows teams to execute well. The belief that productive software engineers are unicorns, however, and need to be valued above all else? That's what destroys companies.

Re: Engineering productivity can be measured, just not how you'd expect

#45

Post by mbrodersen »

The best engineers don’t do much work. They are excellent at delivering the software needed to solve a problem fast and without problems. The worst engineers are always super busy. Fighting fires, starting new fires, rewriting code that doesn’t require rewriting, introducing new shiny tech that will break things in new busy work creating ways etc. etc.

Re: Engineering productivity can be measured, just not how you'd expect

#46

Post by mbrodersen »

strangattractor wrote: post #2

The best teams appear to be doing nothing. If as a general rule things are always in a fire drill then your software sucks (there are other reasons for this). We always measure how many things are fixed. New features added. Rarely how much time is spent baby sitting machines etc.

You nailed it. The best engineers I have ever worked with never worked much. The bad engineers were always super busy trying (and failing) to fix the problems they put in the software in the first place.

Re: Engineering productivity can be measured, just not how you'd expect

#47

Post by cccc4all »

groby_b wrote: post #43
cccc4all wrote: post #32

The process of abstracting away people into units of productivity is common approach to Software Engineering management. It has failed every time. When the latest management fad fails to live up to expectations, new terminology are created to hide the failed management fad. New terminology simply replaces the old terminology and they can now sell new and improved management concepts again and again. Software Engineer…

Productive software engineers aren't "exceptional". If you focus on removing obstacles, you can make most software engineers productive. The point is learning from those who've succeeded before you, instead of claiming it's just magical chemistry happening. Or worse, starting again from first principles. No, that won't produce product-market fit, nor does it open up once in a lifetime opportunities, but it allows tea…

There are reasons why terms like 10x engineer, Rockstar engineer, Ninja engineers are thrown about in the industry.

Google paid Anthony Levandowski $120 Million to lead their autonomous car project, before he went to Uber and the legal troubles. Uber was paying him more than Google.

Facebook paid $16 Billion for What's App, which only had around 50 engineers at the time. Facebook was buying the IP and the productive software engineering members of the team.

There are countless other examples.

No amount of management process can create productive software engineers. That's why companies recruit productive software engineers from other companies. That's why companies buy other companies that has productive software engineers with proven products.

Productive Software Engineers are exceptional. Their work are worth Trillions of dollars and generates Billions of dollars in revenue every year.

Re: Engineering productivity can be measured, just not how you'd expect

#48

Post by babesh »

dacracot wrote: post #39

> Just as a sports team wins or loses together, so too should the engineering team be treated as the fundamental unit of success. A sports team has a play book, does your team? A sports team practices together, does your team? A sports team works as a unit, does your team? Too many times I have see engineering teams as only a team on the org chart In reality they solve tickets as individuals with only a small interac…

Baseball

Re: Engineering productivity can be measured, just not how you'd expect

#49

Post by cambalache »

dacracot wrote: post #39

> Just as a sports team wins or loses together, so too should the engineering team be treated as the fundamental unit of success. A sports team has a play book, does your team? A sports team practices together, does your team? A sports team works as a unit, does your team? Too many times I have see engineering teams as only a team on the org chart In reality they solve tickets as individuals with only a small interac…

Not only that but as every sports fan know the compensation in sports team vary tremendously, even for similar "roles". People in tech would be shocked (with reason) if that were the case in the IT world.

Re: Engineering productivity can be measured, just not how you'd expect

#50

Post by username90 »

andrey_utkin wrote: post #28
dmos62 wrote: post #25

Earlier quoted context omitted.

So what is that true way to measure productivity you alude to? By the way, engineering can be an economic activity, but it doesn't have to be. Could be an art as well, for example.

Simply: does revenue exceed cost of running it? The book I referred to answers the "but engineering team doesn't have revenue". Engineering can be art, sure, and if you like, we can even discount the idea that art creation can be seen as economic activity. But is there a need to measure productivity then?

> Simply: does revenue exceed cost of running it?

Cost of running it includes engineering salaries, so isn't a good measure to include when you measure productivity of engineers. A productive engineer would be worth a higher salary, but if you include the cost of that higher salary reducing his value would that also reduce the salary you want to pay? Doesn't make sense.

Post reply on HN