I’d interperet the cease qualifier in goodhart’s law to require the measure to be good in the first place, but I think SLOC is a negative indicator regardless of whether it’s a target
I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
This is indeed funny, but the 'tribune' role of finding bad law/process and advocating for its removal is missing from most government, corporate or otherwise, and that's bad.
It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
For you, maybe; but to your parentposter's point, it is measured not because it is useful to the overall org, but because it is easy to measure. In that sense, it's a great KPI, when the measurer (presumably some middle management) considers it an indicator of performance.
It's just that you and they define "performance" differently. It's perverse incentives all the way down (or, perhaps, up).
I mean, sure, if you have a sufficiently bonkers view on performance metrics, then, say, index finger diameter could be a performance metric, but in terms of things which could actually be seen by any reasonable person as a KPI, lines of code ain’t one.
Have you MET middle managers in the wild? As I said, most of these metrics are measured because they are easy, not because they are useful. The incentives at that level are to come up with some sort of metric and browbeat people into making it; the incentives for the browbeaten are then to make the number. Doesn't matter what the number means.
That's such a limited view which creates terrible incentives.
If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest).
These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?
I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.
The Platonic ideal of the perfect manager is still going to want to know what's going on when a report isn't checking in commits. I vigorously agree that software quality requires that developers be free to take time to analyze, plan, or just think things through, but zero code days can also indicate a blocker or a performance issue, and a manager should be helping with those.
The most valuable work I ever did, at least in monetary terms, involved zero lines of code (or certainly mergeable lines of code) for significant amounts of time while I figured out if the thing was possible, desirable, tested it, advocated for it… My manager was fine with this.
I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.
the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people. I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out. in fact, in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist. its more like 'I talked to this person and we decided that they should merge an earlier version of their work, because otherwise I'm not going to be able to start for another 3 weeks and that totally blows our schedule'
and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.
the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
> the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people.
Agreed, and this includes managers reaching out to their reports.
> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.
You're imputing an attitude to me which I neither hold nor intended to convey.
> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.
Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.
> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.
