246
Productivity of Rust teams at Google
(programming.dev)
Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”
In small print it says the data is collected over 2022 and 2023.
I'd love to know how they measured this, because if they just took two Jira boards for two projects, compared the ticket times, and said "yep, Rust is good" that's both insane and completely expected by some big tech managers.
I don't deny it, it's just nice to see reasoning with a headline, so that I could take it to another team and say "let's try Rust because..."
@EnderMB @arendjr The used the SI standard unit for productivity, the story point (SP).
Eww... you're probably right. TIHI.
On a related note, I've always preferred t-shirt sizing over story points. You can still screw that up by creating a conversion chart to translate t-shirt sized into hours (or worse, man-hours) or story points, but at least it's slightly more effort to get wrong than the tantalizingly linear numeric looking story points.
If I was truly evil I'd come up with a productivity unit that used nothing but irrational constants.
"Hey Bob, how much work do you think that feature is?"
"Don't know man, I think maybe e, but there's a lot there so it might end up being π."
At the end of the day, the first thing managers do is convert story points / tshirt sizes / whatever other metaphor back into time estimates. So why bother with the layer of indirection.
I'll die on the hill that most teams do not need scrum / agile and all the ceremony that always goes with it.
A kanban board with a groomed Todo column is all you need. Simple and effective and can easily adapt to unexpected scope changes a.k.a production incidents.
*yes I'm aware that if you're getting bogged down in ceremony you're doing Agile wrong. I've never seen or worked in a place where I've felt it's been done right
My company is just doing a kanban board with weekly meetings to discuss the progress and what tickets will be worked on next. The major problem we ran into was when management asked "So, when is the release going to be? When are you done with that project?" about one month before we actually released. I simply had no answer at that point, because that's not something these tickets with no estimates and no velocity tracking can provide.
IMO if it is so hard to do right that somehow no company can figure it out, then the whole system must be garbage. The best we can get to is the direct time estimates so that the "velocity" calculations we're graded on make sense. Still going to be bogged down in ceremony no matter what we do tho.
Yeah, it's different projects, most probably on different levels.
And considering recent layoffs, having different calibre of programmers on each.