Some of my favourite days on the job is when you remove lines of code. Does that metric go against LOC/written?
I once had a senior manager who insisted that developers made at least one commit a day (an internal GitHub like tool gamified this: number of lines committed since last month / top committers in the team etc), and those that didn't, had to up their game.
It was frustrating to say the least as this was not the only metric. There were a handful and, frankly, many made a mockery of it by doing just as much or less work than before but achieving or even surpassing the said metrics.
Few reasons:
1. I find devs (including me) tend to do too few commits instead of too many. Smaller, tighter commits are better, but it's really tempting to try and do an entire feature in one commit.
2. If someone has spent a couple of days working on something without committing it, I'd be concerned that they're stuck, or spinning wheels. I'd check in on them. Not in a bad "you're not working hard enough" way, but in a "do you need help?" way.
3. If someone often spent more than a day without writing anything they could commit, I'd check in on them. Again, like 2. above, not in a "dammit work harder!" way, but maybe it's an indication that they're getting handed the really hard problems, or that they need some more training, or that they're going through some personal stuff, or something.
but measuring lines in each commit is pointless/futile, as is measuring number of commits in a day.
> If someone has spent a couple of days working on something without committing it, I'd be concerned that they're stuck, or spinning wheels. I'd check in on them.
This is more reasonable. Working without review leads to worse fiascoes the longer it goes.
Also encourages testing work to be formally coded and just done interactively. If a test is good enough to compile, commit it as work in progress even if it has a bug and/or incomplete if you've reached a good point you'll like to build upon. Make a tweak, compiles, commit it.
If you've spent most of your day writing a test, but it's complicated and will require even more work before you'd even try to compile and run, commit it WIP before going home.
It worked pretty good because there was only a team of 4-5 people on any product at any time so someone just removing TODOs and not fixing the issues pointed out by the TODOs would have been caught.