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

51–60 of 122 posts

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

#51

Post by voodootrucker »

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…

> 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?

This is why I like XP. Their teams really are teams like you say.

Though I think in many dev shops you can be team like. Someone might like refactoring and cleanup. Someone else is good at rapid prototyping. Another architecture. Sometimes a great dev is just the one who can take the unglamorous tickets and get them done at a sustainable pace. Or someone who is good at devops, teaching, or morale building. Sometimes just communication.

Everyone has different strengths. No one would ever say "who's the best (American) football player?" because you'd have to ask "who's the best kicker, tight-end, defensive lineman". They are all different roles.

To think that football would have the level of awareness that it cannot be measured as a single dimension makes it sad and laughable that people reduce programming skill down to one most of the time.

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

#52

Post by GVIrish »

snidane wrote: post #5
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.

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.

Honestly I don't think most engaged developers who care about their work need the carrot of going home early to develop more robust systems. Most developers who care about their work want to build robust systems, especially if they're responsible for handling outages.

The challenge is whether the organization prioritizes robust systems and devotes resources to making things more observable, reliable, and resilient. The team can want with all their heart to engineer fixes to common failure modes but if the decision makers are always pushing full steam ahead on new features it can be really difficult to improve the app.

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

#53

Post by obiefernandez »

> 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.

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

#54

Post by sinuhe69 »

If you only measure blockers as an index for productivity then two teams with the same number of blockers should always have the same productivity, regardless how the people are? I cannot fathom how wrong this “measurement” can be. Yes, reducing blockers is important but that is not be the only thing the world cares about.

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

#55

Post by karmakaze »

ndiscussion wrote: post #20
karmakaze wrote: post #6

Earlier quoted context omitted.

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

Enough of that is funny 'cause it's true or sad but true. I work at a big co but not a full-on enterprise corp. I value my own time and work, more-or-less in alignment with broader initiatives. Learning new things and technical challenges makes the journey interesting, and it's fun/easy to get work done with most people. Sometimes I have varying degrees of communications (tech vs non-tech or grok/non-grok conceptual) issues but for the most part leadership has enough technical sense to make decent choices. So far, so good.

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

#56

Post by purplecats »

mbrodersen wrote: post #45

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.

the latter get promoted and favored by management. go figure.

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

#57

Post by didibus »

> Each engineering team is unique, so its blockers will be specific. It's not so simple as "more maker time is better." If your engineering team is new or temporarily misaligned on key goals, more meeting time might be the answer. What never changes is the need for measurement and well-considered, deliberate decisions

And we came full circle back to measuring a teams productivity being an art form. Maybe you have a metric now: Hours spent in meetings per week, but nobody knows how much is too much and how little is too little. How do you measure the impact of more meeting on productivity? Or the impact of less meeting? If your measure of productivity is "time in meeting"? This is a circular dependency.

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

#58

Post by didibus »

One thing that wasn't covered here is that productivity is about:

> the effectiveness of productive effort

and

> the state or quality of producing something

Those are quoted from the dictionary definition of productivity, and that definition in my opinion outlines a great insight. Productivity is about the "product" first and foremost.

One thing that's often missing is teams don't have ways to quantify how good the product itself is. Most teams will instead pivot to trying to measure their rate of change to the product. This doesn't mean you have become more productive, because software product is not like food production, more of it is not always better. Better software will instead be about it being more ingenious, more intuitive, more tailored to the problems of its users, more responsive, with fewer malfunctions, etc.

So to me, this whole thing of trying to measure "productivity" which disregards the product from the equation is incomplete. It's trying to measure developer efficiency at changing things, without care if the changes are for better or worse. This includes things like measuring velocity, or line of code, or ticket closed. But it also includes what this article proposes, number of meetings, time to complete code reviews, developer satisfaction with their tools, etc.

All these are trying to see how quickly can developer make changes without ever measuring if the change produces a better product, thus if it actually made the team more productive at effectively positively improving the product.

I'd like to hear about ways to measure software product state and quality. If we had those, you'd have an easy way to know how productive a team would be by seeing how quickly they can improve the product.

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

#59

Post by visarga »

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…

> but like golf where once you get to the tee, it's you and only you to get the ball in the hole

How many times a golf player has demonstrated an idea that upturned the whole field? But this is common place in engineering because it is essentially a creative task.

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

#60

Post by caseyross »

One thing I really like about this approach is that it creates strong incentives for engineers to write maintainable code. Code that is expedient but brittle or hard to understand will be noted as blocking progress for future changes, while robust code can be promoted as blocker-free.
Post reply on HN