My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
As a dev I very much subscribe to this line of thought, but I also have to admit most of the business class people would disagree.
From a business perspective, the developer is the expert in lines of code and the assumption is that expertise should agree on the necessity of a line of code. To create lines of code that do not need to be there is akin to simply not doing your job in this perspective. The finished product should have X lines of code
so from a business standpoint, if equivalent expertise amongst staff is assumed then productivity comes down to lines of code created. Just like how you might measure productivity of a warehouse employee by the number of items moved per hour. Of course if someone just throws things across the warehouse or moves things that dont need to be moved they will maximize this metric, but that would be doing the job wrong - which is not a productivity measurement problem. though admittedly the incentive structures and competition make these things often related
the bigger issue to highlight, imo, is that the business side of things have no idea if coders are doing the job sufficiently well or not, and the lack of understanding is amplified by the reality that productivity contribution varies wildly per line, some requiring much more work to conjure than others. The person they need to rely on validate this difference per instance is the same person who is responsible for creating the lines. So there is a catch-22 on the business side. An unproductive employee can claim productivity no matter what the measurement is.
if the variance of work required per line could be understood by the business side then it could be managed for. I used to manage productivity metrics for a medical coding company, and some charts are more dense and harder to code than others. I did not know how to code a medical chart but I could still manage productivity by charts per hour while still understanding this caveat
the point isnt to use the productivity metric as a one stop shop for promoting and firing people but as a filter for attention, where all the middle of the pack stuff will more of less even out and not require too much direct attention. you then just need to get an understanding of how the average difficulty per item varies by product/project.
that said, maybe lines edited is still a step better - so that refactoring in a way that reduces the size of the codebase can still be seen as productive. 1 point for each line deleted and 1 point for each line added.
I understand that every line should be viewed as a liability, not an asset, but thats the job responsibility of the hired expert to figure out how many need to exist. its not the job of the business side of things to manage.
I wouldnt tell my foundation guys how much concrete to use, or my electrician how much wire to use, but if one team can handle more concrete per hour than another and they are both qualified professionals, it really doesnt seem unreasonable to start off conversations with an assumption that one is more productive than the other. Lazy people do exist everywhere, its usually a matter of magnitude of laziness between people more than it is a matter of actual full earnest capability
"Just like how you might measure productivity of a warehouse employee by the number of items moved per hour. Of course if someone just throws things across the warehouse or moves things that dont need to be moved they will maximize this metric, but that would be doing the job wrong - which is not a productivity measurement problem."
I fail to see how having a measurement that clearly doesn't measure what is actually produced isn't exactly a productivity measurement problem. If your measurement is defeated by someone doing their job badly, what use is it?
nearly all productivity measurements can be defeated by people doing their job badly and trying to game the measurement.
as a business analyst, there are a lot of things to consider to assess productivity and performance at a distance, and no single measurement is ever relied on too heavily - except if the analyst is doing the job poorly of course
It's controversial, but I think it would be tremendously beneficial to our society if we accepted that death is (currently) inevitable and that past some point, assisted suicide is a lot better than artificially prolonging suffering at great cost for as long as possible.
I hold the opposite view on this issue. While I firmly believe that everyone should have the freedom to make their own choices about their lives, my primary concern is that certain groups and especially governments are actively promoting assisted suicide. Even if it's merely coincidental, I find the underlying incentives perverse, for lack of a better word. Admittedly drawing from a Hollywood sci-fi perspective, I would much prefer that, instead of programs like MAID, people were offered options such as cryopreservation.
I would argue that sortition is Democracy. From a purely technical point of view to be anti-sortition is to be anti-democracy, which is fine I guess but begs a lot of questions.
From a practical point of view the selection process is a bit of a red herring though. The current controls break down because the feedback loop is simply way too long to meaningfully affect the process.
While I personally subscribe to the idea that sortition is a superior way of electing representatives I don't see people considering it seriously. However what everyone can understand is using the same process but with sampling with a higher frequency.
Counterpoint, reorgs do happen. Even if someone is doing a fine job, they can find themselves in a completely new team working in a completely new domain just because bodies needed to be buried.
Nail on the head for me, people react to the hypocrisy. Virtual is a prime example. Can't take seriously when a a business advertises how environmentally conscious they are on one hand, but forcing people to commute via RTO on the other.
My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
I've not fully bought the hype yet but actually think LLMs democratizing technical solutions would be a fantastic opportunity for both established players and newcomers. The more LLMs improve, the less of a moat technology is in itself.
IANAL, but my understanding is that in Europe on-call can fall under working time, depending on the exact nature of the requirements. In fact, I'm very interested whether anyone has firsthand experience arguing developer on-call falls under such category. E.g. being 8 minutes away from a work machine and network access is not too dissimilar to a firefighter being 8 minutes away from the fire station.
As a dev I very much subscribe to this line of thought, but I also have to admit most of the business class people would disagree.