by pbrowne011 on 12/19/24, 1:34 AM with 135 comments
by johnfn on 12/19/24, 2:24 AM
I suspect this sort of thing gets promulgated because it kind of massages our ego, like yes, they can measure other sorts of productivity, but not ours, oh no, we're too complex and intelligent, there's no way to measure the deep sorts of work that we do! Which, yes, OK, we're not exactly bricklayers, but surely, if you had to, you could do better.
by voidhorse on 12/19/24, 2:19 AM
A tire factory has a distinct, singular goal: produce tires. It does this continually. Productivity is meaningful, but only in relation to a target that is typically specified by externalities (e.g. amount of demand)
A software company is usually not in the business of producing consumable commodities so this kind of measurement does not make sense. It can make sense to measure productivity during a period for delivering a particular piece of software within a given time bound, but once it's delivered, productivity becomes meaningless. You always need to understand productivity in relation to some purpose and I don't know how these knuckleheads who think this abstract idea is basically like a concrete measurable essence, like mass, or liquid, got leadership positions.
by csb6 on 12/19/24, 2:19 AM
But something is being produced - it is version 2.0 of the software. This is an artifact that is then shipped to users or deployed to a server. Peter’s solution fixed the issue and did not (seemingly) create further maintenance burden, which would have taken attention away from other tasks, i.e. reduced future productivity.
I agree that metrics for programmer productivity are often useless (e.g. using lines of code is a bad idea for obvious reasons), but it seems silly to claim that the entire concept of productivity does not apply to the production of software.
by impure on 12/19/24, 4:23 AM
There is such a thing as productivity in programming. If you could measure it it would likely be some combination of peer review and an analysis of the impact implemented features and fixes had. Some companies actually have programmers rate each other. I don't know how well it works and I think it can lead to perverse scenarios. But you can come up with metrics that are positively correlated with productivity.
by rootedbox on 12/19/24, 2:07 AM
The only thing this article gets at is that engineers may not know how to calculate their own productivity; but it doesn't means it's not calculable.
by dools on 12/19/24, 3:51 AM
Because it also means:
"cause (a particular result or situation) to happen or exist."
by irjustin on 12/19/24, 3:02 AM
It complains, but doesn't offer a solution. It simply criticizes and says "all engineers cannot and thusly should not be measured".
The ironic thing is, the blog post is implicitly measuring by not explicitly measuring. The measurement is the bug ticket itself and whatever value attached to it.
But to this end, I generally agree. There are qualitative and quantitative measurements. Quantitative is the value of the ticket commonly ascribed by the team (scrum? agile? whatever). Qualitative should come up in review.
Qualitative is SO HARD. Top down? Team 360? Mixed? But it must be undertaken and refined by the team at each level of the org. Otherwise you will run into the exact situation described by the blog post and you won't know how to judge left from right, good from bad. Maybe the blog post's example isn't that great, too much information is missing to make a solid judgement, but you need to decide who to reward via promotion, annual raises and who to reprimand and who to not change.
But still, all systems are terrible, but you must pick one less it be picked for you.
by lordnacho on 12/19/24, 10:06 AM
This is simply never going to end if carried on along the lines of this article, or along the lines of most of the comments here.
There's no way to objectively and reasonably put a value on something.
All we have is a theory of subjective value, which does a bit of handwaving about utility and works out some ways where we can come to a price, regardless of the fact that the values in peoples' heads are subjective.
Thus the distinction between knowledge work and "tangible work" like bricklaying is actually a moot point. Yes, you can measure "productivity" of bricklaying in metres per day, but ultimately you care about value, not amounts of wall.
The arguments about one guy definitely being more productive than another are similar. One person values speed, another values maintenance costs downstream. It is subjective what ought to be more important.
by pjs_ on 12/19/24, 3:38 AM
But this doesn't account for the more realistic examples of Prakash, who completely fails to deliver a working solution, or delivers half a solution, and Percy, who gets it done two weeks late. I'm pretty sure you can define a shit_done/time_elapsed productivity metric for those two guys that is worse than that of Peter and Paul.
Maybe I am a cynic but I suspect that some people are upvoting this because the framing makes them feel OK about getting paid six figures to work three hours a day...
by jFriedensreich on 12/19/24, 12:11 PM
by toss1 on 12/19/24, 4:08 PM
My first rule of software programming is: Work Hard to Avoid Writing Code
— Code is habitat for bugs; more code equals more bugs, and interactions between separate parts of code can harbor even more "interesting" varieties.
— Code takes time to run. Any NoOp is faster than even your best hand-tuned assembly module.
Obviously, this is not absolute in any sense — it breaks down as soon as you need the system to actually do something, at which point you must write some code. But it should be the minimal amount to get the job done, and nothing more.
Obligatory car analogy: While doing some amateur sportscar racing, a coach asked me
"What are the things you do that slow the car down?".
I thought for a moment and started saying "when I start into a corner, if I do a bit too much...",
he interrupted saying "NO, no, what are the BIG things you do that slow the car down?".
"Oh, like braking and turning and lifting off the throttle?".
"Right. So what that means is that you should always avoid doing those things. Obviously, you will certainly have to so some of them as soon as you approach the end of the front straight after the start, but make sure you understand your car, the track, and your skills to the point where you do only the absolute minimum."
Both the software and sportscar versions are deceptively simple — they take a LOT more thinking than it seems at first glance. And that thinking is totally worth it.
by manmal on 12/19/24, 3:34 AM
by cushychicken on 12/19/24, 12:41 PM
It is staggeringly hard to measure.
Output is a weak proxy for impact. But it’s the one that makes intuitive sense to people. Doesn’t make it right or useful. I’m sure you all can envision a parable about your subfield of expertise that showcases how a seemingly light touch has a huge positive impact.
by mattmcknight on 12/19/24, 3:20 AM
It becomes clear that simple quantity of code and tickets is not enough- but it's also not nothing. Part of what is missing is quality and assessments of task complexity. Part of what is missing is the other parts of the jobs, like design and code reviews.
I don't think it's hopeless, and can at least be used to look into why some people don't seem to make much at all.
by fuzzfactor on 12/19/24, 2:33 AM
From one point of view, the users of the software are supposed to enjoy so much of a productivity increase that it's not supposed to matter if the coders are as productive as they could be or not.
Give or take a few hundred percent at least.
I realize that most people who've been to business school still aren't going to develop the needed acumen to handle a situation like this.
Too many times the only training retained is a knee-jerk over-reaction to a fraction of a percent :\
Ever see one of these "leaders" have a cow and it was as stupid as it could have possibly been?
I'm confident there are still some natural leaders that can thrive without worrying about every ounce of nose to the grindstone for their staff.
Some things you just can't fix.
by whoisthemachine on 12/19/24, 2:26 AM
by fulafel on 12/19/24, 5:47 AM
Using productivity as a metric leads to the same nonsequitur stuff in many many fields.
It works somewhat for industrial output when you're working with commodities. Or it can work in some more fields as an ancillary measure if you pair it with some other quality, customer satisfaction, outcomes etc measure. But usually you don't want to maximize work while getting good outcomes, you just want the good outcomes.
by wpwpwpw on 12/19/24, 3:35 AM
by jes5199 on 12/19/24, 2:11 AM
by simpaticoder on 12/19/24, 5:20 AM
by robwwilliams on 12/19/24, 2:04 AM
by jascha_eng on 12/19/24, 2:24 AM
It's still true that measuring lines of code, time spent coding, commits or anything else is at best a proxy of productivity. It's also true that without any code changes problems more often than not don't get solved or we at least can't call the activity software development.
by mprast on 12/19/24, 2:22 AM
by sanitycheck on 12/19/24, 11:09 AM
by jschrf on 12/19/24, 5:21 AM
Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.
See: Out of the Tar Pit.
by popcorncowboy on 12/19/24, 1:34 PM
by tbrownaw on 12/19/24, 2:34 AM
by eacapeisfutuile on 12/19/24, 3:55 AM
by akst on 12/19/24, 4:42 AM
by timeforcomputer on 12/19/24, 2:37 AM
by revskill on 12/19/24, 3:14 AM
by wcfrobert on 12/19/24, 4:14 AM
Using lines of code to track productivity is absurd (do people really believe it or is it just a strawman at this point?). I'm reminded of that midwit meme where a junior has very few lines of code written because they don't know the code base well enough, the midwit writes up an whole framework, and the senior engineer has a net negative lines of code contribution.
Theres also a fundamental difference between creating and maintaining code. Something like 10 guys wrote visicalc. Does that mean they were contributing millions of dollars in profit per hours? What about the maintainance to keep it going? Bug fixes? Patches? On call infra guys? What about opportunity cost of putting engineers on deadend projects?
My point is tracking productivity in software dev - maybe all knowledge work for that matter - is complicated. Maybe that's why there's so much "busywork" (emails, slack, tickets, meetings, etc). Everyone wants to look productive but no one knows what it means
by 0xbadcafebee on 12/19/24, 4:34 AM
"Put another way, productivity has no applicability as a metric in software.
"How much did we create today?" is not a relevant question to ask. Even if it
could be measured, productivity in software does not approximate business value
in any meaningful way. This is because software development is not an activity
that necessarily produces anything.
Which of these two developers was more "productive" today? The answer is: It doesn't
matter. What matters the that Peter solved the problem, while simultaneously reducing
long term maintenance costs for the team. Frank also solved the problem, but he
increased maintenance costs by producing code, and so (all other things being equal)
his solution is inferior. To call Peter more "productive" is to torture the metaphor
beyond any possible point of utility.
Productivity does not mean "increases business value while decreasing maintenance costs [and having no net negative impact in any way]". It doesn't even mean "solving a problem".
Productivity just means "to make something", or more specifically the rate at which something is made. That's all. You can make 10x more of something, and it can be garbage quality, but you did make it, and you did make more of it, so your productivity increased.
If you produce 10x more grain than you did yesterday, you are more productive. The grain might now be full of heavy metals, pesticides and toxins. But you did in fact produce more grain. If you were trying to measure productivity of usable, healthy, high-quality grain, that is a different measurement than just productivity of grain. You may assume everybody knows what you mean when you say "productive", but you'd be wrong.
by fermigier on 12/19/24, 8:52 AM
by vonnik on 12/19/24, 8:45 AM
by lazyant on 12/19/24, 6:15 PM
by danielmarkbruce on 12/19/24, 3:23 AM