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.
At my last Java job, whenever there was a day I didn't have much or any code to commit (e.g. I was in the middle of going through compsci papers about a nontrivial algorithm I intended to implement), I would open up the IntelliJ's "code inspections" tab. It provided me with a never-ending stream of quick and small fixes to make that not only amounted to a commit, but also occasionally fixed an actual (if not likely) bug.
It's quite normal for it helpdesk teams doing all the users password reset tickets to "outperform" the teams fixing server issues based on "tickets closed" metrics
I know I'm against popular opinion to the extreme here, but I'm not altogether against that (the commit every day bit, not the LOC competition bit).
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.
I can sort of see the rationale for this, but it's been a long time since I've worked anywhere where this was feasible even 50% of the time; nobody wants fragments of a feature in trunk, and the codebases tend to be inflexible. "Commit to branch", sure; branches are cheap.
> 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.
If you do work in progress (wip) branches where you're not concerned with breaking the build and then rewrite the history to not break the build after (counts as new commits) this becomes more viable.
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.
The only place I've ever been at that had any sort of lines of code measurement also tracked lines removed, This was on a points system and in fact removal of code was considered worth more points as long as it didn't break build (there was also some other stuff about if it was rolled back or the lines you had written were changed in a short time that points were removed)
There was also some points for removing TODOs etc.
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.
