I would be interested in hearing your thoughts on ways to understand (intentional not saying measure) productivity of software engineers with metrics. I know it's a polarising topic and difficult to tackle. Usually the path of discussion goes to "commits are not relevant", "my situation is unique", "requirements are changing", and so forth. But in the same time, after so many projects delivered and considering the maturity of tooling we have today (acknowledging that this make it also very complex), there are many, many things which are kind of predictable and similar to other delivered products. Outside a small percentage of developers which work on innovations, r&d and areas which by nature are unpredictable, the vast majority are just doing the same stuff.
So what are your ways of understanding that someone is productive or not which is not based on gut, perception and other subjective factors?
The thing to understand is that software is not useful in and of itself, it is only useful for automating or increasing the efficiency of some other endeavor.<p>If you imagine, say, a hotel, it has plumbing that makes the toilets flush, and an accounting department that pays the bills and stuff, but none of those are an important driver of how people choose their hotels. Upgrading the plumbing will not lead to more guests, but if the plumbing breaks, that can lead to a negative experience and needs to be fixed quickly by a competent plumber.<p>It's the same with software - you need to figure out what the actual end goal is (more sales? attract a new client? more reliability?), and then the productivity of the developers measures how their software changes contribute to that outcome.
Almost everything in software development is in a constant state of change. The languages, the libraries, the frameworks, the development tools, the protocols used to transmit data, the platforms you host on. Even though we’re doing the same thing over and over again, it’s not really quite the same. Even something done so often as auth has so many requirement nuances to make each environment unique.<p>This would be like trying to build a skyscraper but having to keep up on a dozen changes to the raw materials every year. Each time something materially changes you rebuild the entire thing with that change.<p>All you can reasonably measure is how well the process is going, which is why you have efforts like DORA and SPACE. They effectively try to measure the state of flow that developers need to be most productive.
The problem with metrics on coders who are just doing run-of-the-mill tasks is that even if you do find a good metric... when they want to push beyond run-of-the-mill and start innovating, they now look bad. You ultimately end up incentivizing coders to game the system, not to build quality code.
If you have test automation in place this becomes instantly simple: how much time does it take to deliver a solution with minimal test coverage that also passes prior test coverage?
In my position productivity can be safely measured by total number of hours spent on the tickets every sprint. I'm most focused on stories and tasks but we also log spikes as researches.