51–60 of 145 posts
Good productivity is about being able to do all tasks as planned. That includes the management, as its task is to attribute tasks. And whoever creates tasks. And whoever defines the objectives those tasks should answer to.
Earlier quoted context omitted.
> 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. Productivity is not a cut-n-dry stat for any kind of knowledge work. For an admin, we could say they were more productive…
> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc? I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my wor…
Earlier quoted context omitted.
Ok, but then what is a way to do it? The text gives an example to the core problem, and to argue differently requires thinking around it. In practice. I’ve seen many attempts at measuring productivity, but once you dig into them, you see they are just abstraction mechanisms above something that is similar to lines of code. I have yet to see an idea that sidesteps the core issue described in this post. Also, it applie…
I recommend measuring job satisfaction instead of developer productivity. It's the "least bad" proxy metric I know of. https://redfin.engineering/measure-job-satisfaction-instead-...
A potential riske seems to be feedback systems where job satisfaction is determined by high or low pay.
> I would argue that what good software developers do is remove problems. The opposite, in fact, of production 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 futu…
Silly and convenient. No one takes the claim that you can’t measure software productivity seriously and everyone simultaneously agrees that simple scalar metrics often fail to show the big picture in any and all disciplines. The rest is just usual software guy hubris and lack of awareness of the discipline.
At least three people do, and they are mentioned in the article: the author, his colleague, and Martin Fowler.
I suspect that software productivity (like the productivity of scientists, artists, composers, etc.) on any non-trivial project may be measurable on a scale of years, but not necessarily months or calendar quarters. A larger issue is that productivity is often due to external factors as much as it is to individual effort, and overnight success is often the result of extended periods of limited progress or even repeated failure.
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
Earlier quoted context omitted.
> 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. Productivity is not a cut-n-dry stat for any kind of knowledge work. For an admin, we could say they were more productive…
> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc? I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my wor…
I'm not sure I follow. So you failed to measure software productivity in lines of code, therefore it follows that "There's No Such Thing as Software Productivity"? Don't you think that giving up after n=1 attempts at measuring software productivity might be a tad too fast to draw a generalized claim of impossibility? I might argue the real lesson learned is "Lines of Code are Not a Measure of Productivity in an Isola…
> 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. Productivity is not a cut-n-dry stat for any kind of knowledge work. For an admin, we could say they were more productive…
For individual, productivity is measured on multiple axis - new long-term features, throw-away and prototypes, code maintenance, fire-fighting, code reviews, high-level design, outside-of-team communications, intra-team communications (for example helping teammates), archeology, specific parts of your project, probably others. In ideal team, everyone is strong on at least one or two axes, so no person is worse than others. In real teams, I've seen people who were weak on every single axis and did not seem to improve with time. I've also seen people who are great at everything, and it's extremely nice when such people exist - but they are very rare.
(Btw, re your specific example: if you weren't productive because you were waiting for others to approve your access then you were not productive. There is nothing complex about this, there were plenty of times when I've said, "I did nothing for project S last week because they still could not give me access")
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.
Earlier quoted context omitted.
> 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. Productivity is not a cut-n-dry stat for any kind of knowledge work. For an admin, we could say they were more productive…
> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc? I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my wor…
What are your eyes measuring? Are you being fooled?
"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.