Re:Some reasons to work on productivity and velocity
by Jensson on Friday October 15, 2021 @06:41PM
(#28883978)
That has to do with managers being bad at telling how productive a team is, it is a completely different problem.
Re:Some reasons to work on productivity and velocity
by tdeck on Saturday October 16, 2021 @03:19AM
(#28886173)
OK, what you're saying definitely applies when we incentivize speed and forget everything else, or when we compare ourselves to others without knowing the whole story. But this current discussion is in the context of someone's personal goals to improve their own productivity from their existing baseline. Valuing that doesn't necessarily mean they have to stop valuing quality or maintainability.
However, can one also go much faster by: not writing tests one ought to have written; ignoring security issues; ignoring input edge-cases; ignoring output edge-cases; treating a variety of variables as constant, or as having bounds that they actually do not; not writing enough documentation; et c.? Oh my god, yes. Of course.
Anyone who's ever seen a "we're really happy with the output of our outsourced team on this Rails 'app', they've gotten this MVP ready so fast!" codebase knows that's definitely also a way to be fast, and that a team writing actual quality code and not putting in a ton more hours couldn't have matched that team's "productivity", because they'd have been doing way more work.