31–40 of 222 posts
Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
That bug was left unfixed for months but now it's solved. Should I have received a talk because of that?
(Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
The cynic in me believes managers actually don't want good metrics because then they have evidence of their bad leadership.
It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.
I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
>In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands of lines of code as a measure of programmer productivity. "All they cared about," raves Ballmer, "was KLoCs and KLoCs and KLoCs." IBM, apparently, did not care whether the code was any good as long as there was a lot of it.
A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod).
But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
The scalar of «amount of code that a developer writes» is «devoid of any meaning» outside frameworks of streamlining of such code (which would themselves not be a good idea, as you would in fact actually have classes of code, to be judged differently). The submitted specifies it was a case of a simple scalar field in a form.
Your argument is of course valid, but your conclusion disregards it. Outside a defined framework of quality adherence, the «amount of code» is «a random number».
The interesting part is all in the productivity (bulk of quality). That is the area that should be investigated - in both discussion and assessment.
And clearly, "amount of code produced" is a bad incentive, against quality. Aaaalways take care and beware of incentives.
Earlier quoted context omitted.
But they ARE a KPI that is easy to understand and measure.
How can it be a KPI if it doesn’t measure performance?
It does measure something, not necessary something useful but zero LOC indicates trouble.