[GVIrish]

> Managing to metrics is harder, because the metrics (bugs retired, KLOCs written) are so meaningless and easily fudged.

Agreed, managing to team metrics is usually the road to hell. But tracking some metrics can uncover problems. Maybe your team is bad at estimating. Or there's a lot of rework to new functionality due to shifting requirements. Or maybe there are a lot of bugs after a release because the engineering process is broken somewhere.

> Also, good programmers tend to be undisciplined.

I find this to be untrue. You're not really a good programmer if you ignore the ancillary activities that contribute to a high-functioning project/team, unless you're someone who is writing code only for yourself. Communication, coordination, documentation, and following good processes wastes less time, reduces mistakes, and reduces the damage done when someone leaves the team.

The cowboy programmer can do a good job writing code but if they're not attending to all of the other stuff a software engineer needs to do, they are dragging down the productivity and resilience of the organization.

> Replacing them with mediocre but disciplined programmers doesn't usually improve things.

Yes you'd certainly rather have a good programmer who needs to improve on process than someone who can barely program. But even better to have someone who is both disciplined and good.

[dsr_]

"Maybe your team is bad at estimating."

To a first approximation, everyone is bad at estimating software development times.

See: https://news.ycombinator.com/item?id=12149515 and https://news.ycombinator.com/item?id=4328660 and http://www.romenrg.com/blog/2015/09/28/why-asking-developers...

and The Mythical Man-Month, too.

[GVIrish]

Certainly there's a lot to estimating in software dev, but I'm talking about when estimates are regularly wildly out of whack. Where someone or a team regular estimates something will take a few days but then it takes several weeks or months it indicates there's a problem or problems somewhere.

Maybe requirements are shifting too much. Maybe there's a lot of hideous technical debt. Maybe the wrong technology is being used to build the product. Maybe there are people on the team that don't have the skill level they need.

There could be a lot of things at play there, but the point is that there may be issues that need to be addressed. When you see wildly inaccurate estimates it means the root cause(s) should be investigated.