This to me smells of a product owner, executive BA or non-tech-savvy director who really wants to see more productivity, while ignoring the true meaning of productivity in the software industry (some devs like to make a few, significant commits while others make loads of tiny commits of little impact).
Let me just address the many issues with each "demand" one at a time:
Number of commits per week
Lines of code changed per week
This tells you nothing, anyone can make 100 commits in half a day while having no impact on the overall system. If anything it encourages the less-than-engaged developers to just make loads of tiny commits like reformatting, quality control, removing white spaces, changing the target framework and then changing it back... a bored developer gets really creative if they only need to "make more commits".
I wonder if my manager thinks I am an idiot that I cannot figure that
Like you said, this is a VERY hackable way of boosting your review points, if you think the new policy is stupid (you're not the only one) then by all means hack it. If your manager is code-savvy then you just need a reasonable explanation/description of each commit. Otherwise, you can commit whatever you want, however you want so long as it doesn't break the build or pipeline.
PR review times
This tells you nothing on it's own. Yes, it's generally bad to need loads of PR reviews and revisions for one piece of work, however it can be very circumstantial. What if your trying to PR a major breaking change with integration tests but the system changes very frequently? You can either ask the rest of the devs to stop working for a bit or you just have to tweak, tweak and tweak that PR until it's ready for release. Sure, silly mistakes are a red flag but I've made dozens of PRs where they would have passed I raised the PR but then, hours later, someone else change the master branch and I have to tweak my PR in order to let it build. Happens all the time. This is why it's imperative to have a team lead who can orchestrate PRs in a way that will never break the build.
Error log entries generated
On face value, this seems appropriate. I.e. more error logs means your making more mistakes, but where do these errors come from? Compile-time errors are 100% unacceptable (even if they're possible to commit) but run-time errors and exceptions usually get bubbled up through the many layers in a large scale system. E.g. there may be a low-level programmer who pushes a core fundamental change to the system, which still works fine. But then there may be code in a much higher layer like the front-end which could malfunction for a multitude of reasons (sometimes it's down to the user's device, sometimes it's down to a bloat of 3rd party frameworks, sometimes it's down to other developers using different IDEs, the list goes on). In all honesty, this shouldn't even be part of a performance review process, it should be an ongoing discussion between Devops and developers. In today's standard of software development, it can be a real pain to even find where an error is logged (server, client application, browser window, cloud host instance) for this reason I would always have a central log repository like Splunk with a dedicated log watcher who knows exactly where each message originated.
Second, these metrics are going to cause me to actively harm the
codebase in the hunt for a better score. #NotMyProblem long term and I
will do it if required, but I would rather not.
I couldn't agree more! Your company has basically imposed a competition between the developers, except this competition has no real reward, no guarantee of improving company performance and honestly it's more likely to do the opposite.
Are there some other numerical (required by the guy on top of the pile) metrics that are easy to collect that we could use instead?
Yes, but you need a very experienced software engineer to keep track of these metrics (and the developers who do the work, which areas are they focusing on and how much control they have over the underlying system/legacy code).
Some useful examples of productivity metrics:
- (PR review time-to-number of changes) ratio, if a small PR needs loads of revisions then it's a bad sign, but it's normal for larger PRs to have
- Customer Feedback/ Bug Reports If you give customers the opportunity to rate your software then it's very beneficial to know what works and what needs work. If a certain dev gets repeatedly poor feedback on most of their work it's a bad sign.
- Gantt Chart Accuracy Dunno if your team uses Gantt charts, they are very helpful for long term goal tracking, If your developers can plan work 8 weeks ahead of time and finish said work on time you can rest assured they are not only reliable but also realistic in their goals. Those are the two most important factors in my opinion when it comes to having a solid, productive team. You can't ask developers to achieve any goal in any time frame, but if they can consistently achieve goals in the time frame they estimate, then THAT'S AS GOOD AS IT GETS (without hiring some Rockstar contractors)
- Story Board Points This is like a more agile way to keep track of Gantt charts, so long as your team is realistic when setting the points of each story board item, you can use the points per week metric as an indicator of progress.