This sounds like a bunch of drivel.
AI can better analyze the relationship between cycle time, code review time, and code churn… It can determine if longer code review times are actually leading to less code churn… Or, it may find that longer review times are simply delaying the development process without any significant reduction in churn.
This is not something that the numbers tell you. This is something an understanding of the code reviews tells you. The author runs a metrics platform so he’s pushing this hype train that’s going nowhere. Blind faith in metrics without context, ie all an AI can generate, leads to great decisions like the Nova.
My experience has been management is too stupid to properly employ metrics. If you let them pick, they pick the easiest ones. If they don’t get a choice, they just try to cheese the numbers to the detriment of the company. If you present options that make sense, they don’t understand them.
Maybe I’ve just worked for dumb companies, but they sucked hard with respect to metrics.
As an engineering manager who’s tasked with manually gathering a whole lot of metrics in the hopes that something jumps out that can then be improved, what would you say are the metrics that make the most sense?
As a former coder, I would say PR size (the smaller the better), automated test coverage, number of prod bugs, toil level (unplanned work, dealing with tools and environment issues) but also things like knowledge of the code base, level of collaboration, ownership of the process, org-wide collaboration and learning… Much of which is hard to measure but can be set as goals regardless.
Apologies if I misled you a bit. My experience is in manufacturing, not coding. My advice would be to identify issues in terms of cost. That’s what the company truly cares about. Talk to your people and find out what their biggest pain points are. Then order those issues in terms of effort to rectify vs return on investment. Problems that are low effort but high return get prioritized. Then just whittle the list down.
This takes a broader approach to metrics. But as I mentioned, metrics can be cheesed. It’s hard to cheese overall cost. If you prioritized number of bugs, I’d assume the time would go up. If you prioritized time, I’d assume bugs would go up. Prioritizing either doesn’t really solve the problem. You want the root cause of those bugs. Are certain bugs more prevalent (can bugs be categorized even?). Then work those down.
I’d be more then willing to flesh out some more details if you’d like. I genuinely love that kind of stuff. Unfortunately I don’t have coding specific experience.
This is the best summary I could come up with:
Over the decades, engineering management has undoubtedly become more agile and data-driven, with automated data gathering improving performance.
It can automatically set goals based on real-time data, generate recommendations for improving teams’ performance, and process far more information than was possible before.
Even the most capable engineering leaders have some blind spots when it comes to reviewing performance in certain areas, and may miss concerning behaviors or causal factors.
Typically, managers will manually put together reports at the end of the month or quarter, but often that gives a superficial analysis that can easily conceal hidden or incipient problems.
Or, it may find that longer review times are simply delaying the development process without any significant reduction in churn.
By analyzing multiple metrics simultaneously, AI can help identify patterns and correlations that might not be immediately apparent to managers, enabling organizations to make more informed decisions to optimize their software development processes.
The original article contains 424 words, the summary contains 152 words. Saved 64%. I’m a bot and I’m open source!
Even the most capable engineering leaders have some blind spots when it comes to reviewing performance in certain areas, and may miss concerning behaviors or causal factors.
blind spots - something the AI has too?
A capable manager may make use of known unknowns. Using an AI where you can’t follow the process seems risky. Asking the AI to explain itself may be elaborate hallucination.
