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

111–120 of 122 posts

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

#111

Post by sdesol »

michaelt wrote: post #101
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. If you're trying to sell this concept to developers, you might want to change "discourage" to "hire more than one"

Ideally you would like to hire more than one, but I think my use of the word "discourage", was not the right one. What I ultimately wanted to say was, you want a balanced team, where no individual development pattern sticks out.

A very high impact employee could easily be the result of having multiple poor employees, improper planning, and so forth.

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

#112

Post by andrey_utkin »

blackbear_ wrote: post #109
andrey_utkin wrote: post #105

Earlier quoted context omitted.

See http://www.hubbardresearch.com/wp-content/uploads/2019/06/In...

Calibrated estimates with huge uncertainty ranges are still useless, even if calibrated. "One month of refactoring this component can save us between 500k and 50M in the next five years with 90% probability" - this is not very useful for the decision maker, yet it is quite difficult for a domain expert to narrow the range.

It is possible, and in some cases practical, to spend more resources to obtain more information which narrows the range. That's what Applied Information Economics methodology preaches.

Page 5 of author's intro booklet has a flowchart which conveys the idea: http://www.howtomeasureanything.com/wp-content/uploads/2014/...

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

#113

Post by prepend »

I like that the article kind of gives up metricing and just says each team should figure it out. This is kind of similar to the no metrics he proposes.

If I had to choose, I’d choose no metric over lines of code or number of tickets, etc.

I think the issue is that when orgs get big enough they have lots of teams and having some comparability is useful to find lessons learned to spread among teams, etc. I don’t know of any metric that is truly objective for figuring out high productivity teams or individuals just by using it.

I think there are some “vital signs” that you want projects to have, but don’t want to fixate on the actual value. Like you don’t care if someone’s pulse is 70 or 80 or 90, but you want to make sure pulse is checked.

I think having reviews in git is helpful and not having any is something to look into.

I think having contributions from other teams is a good sign, although absence isn’t necessarily bad. I think the positive is by showing how others are finding and asking questions or reviewing or contributing material so that’s probably reuse.

I think encouraging information sharing through lunch and learn presentations is good, but is delicate to avoid gaming from people just “making the circuit.”

Having an automated CI/CD is a good sign and if code is making it to prod without one, it requires looking into.

Theoretically a healthy team will have all these signs, but you could have an awesome team with low numbers and a terrible team with high numbers. So these metrics wouldn’t be useful for detecting productivity and comparing across teams, but would be good for just finding big, lurking problems.

I comically work in an org where there are whole teams not using source control, so the “only I can measure myself, give me more money” is a very real challenge.

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

#114

Post by prepend »

obiefernandez wrote: post #53

> If your team is full of competent, driven engineers, removing their blockers is the fastest way to enable forward movement. That's a HUGE if right there. In my experience, the most problematic teams I've ever worked with were simply full of incompetent and/or unmotivated engineers, and for whatever reason it was impossible to replace them.

I think the challenge with this is that blockers only get removed once and super awesome teams preemptively remove blockers before they block.

So while it’s good to remove obstacles and maybe helpful to measure if obstacles exist that’s bad, it doesn’t mean much when no obstacles exist and none have been removed in a long time. Maybe they are super awesome and chugging along from all those removed obstacles. Maybe they are super sucky because they don’t see things as obstacles.

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

#115

Post by prepend »

nitwit005 wrote: post #80

I have to disagree with the idea that sales is somehow becoming a scientific process due to CRM. There are openly gut feeling fields like how a call seemed to go, how "hot" an opportunity is, etc. Most of the ideas predate software as well. People had remarkably complex paper based sales systems.

I’m not in sales but I remember my firm having sales pipeline meetings 20 years ago where sales people would talk about stuff that happened. It was all manual and anecdotal. So the sales pipeline was only in someone’s head or maybe a spreadsheet they hacked out once a quarter or whatever.

I think the difference today that the author referenced is that with Salesforce stuff like number of leads, contacts, conversion, revenue and profit per conversion, etc is all captured and reportable in sort of real-time. There’s still lots of gut inputs like how the meeting went or having people estimate probability of closure, etc. But now it’s more systematic.

I don’t know if it’s more successful, but it seems like I get more sales calls and repeat contact attempts.

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

#116

Post by prepend »

wuweipractioner wrote: post #71
rajacombinator wrote: post #44

Let’s see an article about measuring manager productivity.

IMO a manager's productivity is measured based on how well their team performs(or how well they present their team's productivity) and this article provides an approach on how to do so.

So the more blockers a manager removes, the better the look to their manager.

It’s turtles all the way up.

I actually think that one’s compensation is correlated to how ambiguous the job duties are and how hard it is to measure success, given employment.

Stuff that’s easy to measure gets commoditized. Stuff that’s hard to measure, but still important is hard to staff, creates risk and is easy to mitigate with money.

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

#118

Post by chrismcb »

908B64B197 wrote: post #107
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…

>> 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? It's a great analogy, but the author should also keep a couple things in mind: - Out of all the football teams in the world, only 32 can ever w…

While there is money in the super bowl, most of it isn't and it isn't winner take all.

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

#119

Post by visarga »

andrey_utkin wrote: post #89
visarga wrote: post #66

Earlier quoted context omitted.

> Engineering activities productivity can be measured the same way the productivity can be measured for any economic activities. The economy is basically a population based evolutionary process. Its nature is open ended - things that seem important now might have been seen as being useless or stupid a decade or two ago, like neural nets in 1985 and personal computing in 1950's. So we can't tell ahead of time which wi…

So what's your point? Mind you, we're discussing an article on engineering productivity in business. Nothing is happening without funding. Business can't run producing things which are not valuable in the moment, it will go bankrupt. Government can sponsor such things as it sees fit, best if guided by a clear hypothesis that funding it makes the outcomes probabilistically better than not funding it. When nobody is pa…

That's exactly my point - following the gradient of money you won't get to the global optimum because it's just a short sighted signal. You need to invest into crazy ideas to get anywhere. Unknown unknowns don't get discovered in a systematic way and are not profitable step by step.

If your name is Christopher Columbus and it's 1492, your project gets rejected for being implausible, what do you do?

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

#120

Post by nytgop77 »

visarga wrote: post #119
andrey_utkin wrote: post #89

Earlier quoted context omitted.

So what's your point? Mind you, we're discussing an article on engineering productivity in business. Nothing is happening without funding. Business can't run producing things which are not valuable in the moment, it will go bankrupt. Government can sponsor such things as it sees fit, best if guided by a clear hypothesis that funding it makes the outcomes probabilistically better than not funding it. When nobody is pa…

That's exactly my point - following the gradient of money you won't get to the global optimum because it's just a short sighted signal. You need to invest into crazy ideas to get anywhere. Unknown unknowns don't get discovered in a systematic way and are not profitable step by step. If your name is Christopher Columbus and it's 1492, your project gets rejected for being implausible, what do you do?

Pitch it to different investors. His own country Italy did not fund him, so he pitched it to Spain.
Post reply on HN