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

11–20 of 122 posts

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

#11

Post by BossingAround »

kamilafsar wrote: post #7
snidane wrote: post #5

Earlier quoted context omitted.

The best way to motivate devs to build truly robust systems is to let them go home at 2pm when things are finished and production process is running smooth. However most organizations would pile more work onto devs if they finish early, so devs then compensate by taking more time on their current tasks. Why finish them early, when you'll be thrown another one right away.

Finish what? Where do you draw the line of “work for today”? I don’t think motivated devs want to go home at 2pm. Speaking as a dev, the best way to motivate me is to give me some head cracking challenge, trust (no reporting) and autonomy (don’t tell me how to do my work).

> I don’t think motivated devs want to go home at 2pm.

I can understand the attitude when one's in their twenties, has no significant other, kids, or other commitments.

Me? I just get tired. I'm very motivated and like what I do, but at some point, it's just silly to stay behind the screen. And sometimes, that point is even earlier than 2pm. That's ok. We aren't machines to be working like a Swiss watch.

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

#12

Post by snidane »

The article is correct to point out that in case of no process measurement, politics, not results, will start to dominate.

Measuring process inputs will favor Sisyphean work. Appearing to be working, hours punched in and butts-in-seats will be more valued than results. Many companies are stuck in here.

Measuring proxies of outputs such as lines of code, or number of tickets closed, as the article mentions, only leads to people gaming the system.

Measuring the actual value delivered is obviously the best thing to do. However it is often difficult to even define value and the amount of it created. Which is always a problem especially for inhouse projects or in the absence of direct contact with the market.

I like what the article suggests - measuring process flow instead of measuring inputs or outputs. Can't say exactly why I like it but it seems that engineer types are naturally motivated to perform and learn, so giving them enough space is a good way to get working systems as a side effect.

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

#14

Post by maximente »

emteycz wrote: post #3
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.

Sadly business people want to fire you when you're seemingly doing nothing (as in coming to work on time, doing your job without stress and conflict, going home on time)... Even if all the business goals were met, they just can't stomach someone not working their asses off 24/7 for them.

well, yeah. if you don't have air cover from a team or manager and don't appear to be engaged in shared suffering, it's no surprise people are going to ask questions, both from above and equal level. other labor will resent your non-suffering (how come /they/ get to leave on time?) and management will wonder whose reports get such a cushy setup and why.

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

#15

Post by snidane »

kamilafsar wrote: post #7
snidane wrote: post #5

Earlier quoted context omitted.

The best way to motivate devs to build truly robust systems is to let them go home at 2pm when things are finished and production process is running smooth. However most organizations would pile more work onto devs if they finish early, so devs then compensate by taking more time on their current tasks. Why finish them early, when you'll be thrown another one right away.

Finish what? Where do you draw the line of “work for today”? I don’t think motivated devs want to go home at 2pm. Speaking as a dev, the best way to motivate me is to give me some head cracking challenge, trust (no reporting) and autonomy (don’t tell me how to do my work).

> I don’t think motivated devs want to go home at 2pm.

That's the beauty of it. Motivated engineers will use the spare time after 2pm to study and improve things. Or run some errands if they have to, without feeling their butt has to be glued to the chair until 6pm.

I've often solved many problems at work in my spare time or when taking a dump or something. It's pretty difficult to really get into deep thinking at the office because of 1. noise and 2. looking unproductive when you actually think hard.

Paradoxically office slackers bashing keyboard when chatting on facebook look more productive from a distance than somebody who actually is deeply thinking about system design and spinning in a chair or staring at a ceiling while doing it.

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

#16

Post by andrey_utkin »

Engineering activities are economic activities.

Engineering activities must make sense as economic activities.

Engineering activities productivity can be measured the same way the productivity can be measured for any economic activities.

See "Internal Market Economics: Practical Resource-Governance Processes Based on Principles We All Believe In", Book by N. Dean Meyer.

The posted article came so close to the idea of the right measurements, I was intrigued and was like "yes, say it!", but the author didn't say what I expected, instead they pointed at quantifying calendars and commit logs. What a bizzare self-contradiction.

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

#17

Post by horsawlarway »

bjornsing wrote: post #8

> Engineers will become more focused and engaged, managers will become more effective and empathetic, and companies will build faster with higher quality. Engineering will rise to a whole new level. A bit too much hyperbole for my taste, given the less than groundbreaking ideas.

I mostly agree - This doesn't seem to be adding any real visibility that velocity tracking (a la - agile) wouldn't give you already (not that I'm advocating for agile, mind you...).

Consider -

I have two teams, with the same staffing levels and the same general seniority. For this example, lets assume each is a team of 5, with 1 tech lead, 2 seniors, and 2 juniors.

Both teams have the same approximate meeting count, both work on the same stack with the same dev tools.

Team A consistently releases new features faster than team B. Why?

Because if the answer is "Find the blocker" aren't we right back at

> "your engineering leaders will simply justify failures, telling stories like "The customer didn't give us the right requirements" or "We were surprised by unexpected vacations.""

except with blockers this time?

Maybe Team A is actually just better than Team B.

Maybe Team B is actually working on a feature set that has more inherent complexity.

Maybe Team A releases faster but also has more incidents in prod.

Maybe Team B releases a larger changeset on average.

None of this is getting addressed or answered.

----

None of that is to say that measuring blockers isn't a useful idea, but it's certainly not some silver bullet.

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

#18

Post by mr-wendel »

snidane wrote: post #12

The article is correct to point out that in case of no process measurement, politics, not results, will start to dominate. Measuring process inputs will favor Sisyphean work. Appearing to be working, hours punched in and butts-in-seats will be more valued than results. Many companies are stuck in here. Measuring proxies of outputs such as lines of code, or number of tickets closed, as the article mentions, only leads…

I like it too, but I think it misses something crucial: how often is the team unblocking others? This, naturally, is at odds with minimizing interruptions.

On one extreme there is no shield around engineers and they experience constant whiplash with "code oracling", shifting priorities, obscure trivialities, and other things that can drive people insane and can prevent meaningful work from being completed.

On the other hand, sticking perfectly to "we're committed to this sprint and unless its on fire you wait in line" and much of your business becomes unnecessarily rigid and painful. That, IMHO, is much worse.

Finding a balance is crucial, and to me thats just as interesting of a datapoint.

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

#19

Post by [deleted] »

snidane wrote: post #15
kamilafsar wrote: post #7

Earlier quoted context omitted.

Finish what? Where do you draw the line of “work for today”? I don’t think motivated devs want to go home at 2pm. Speaking as a dev, the best way to motivate me is to give me some head cracking challenge, trust (no reporting) and autonomy (don’t tell me how to do my work).

> I don’t think motivated devs want to go home at 2pm. That's the beauty of it. Motivated engineers will use the spare time after 2pm to study and improve things. Or run some errands if they have to, without feeling their butt has to be glued to the chair until 6pm. I've often solved many problems at work in my spare time or when taking a dump or something. It's pretty difficult to really get into deep thinking at th…

[deleted]

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

#20

Post by ndiscussion »

karmakaze wrote: post #6
ndiscussion wrote: post #4

Earlier quoted context omitted.

It's about power not money.

That's actually insightful. Wish I'd known this early in my career. Often, I'll be doing a great job with no complains from peers or project deliveries but seemingly 'tolerated' and not liked by any management types as they had no influence, I just did what needed doing of my own accord. Or maybe I didn't need to know, ignorance was bliss.

Check out this post: https://daedtech.com/defining-the-corporate-hierarchy/

I really recommend his book Developer Hegemony, although it was very depressing and I haven't quite recovered a year later :D

Post reply on HN