Managers Like Measurements

Managers need to be able to predict the amount of time and money needed to complete their projects. Many managers are taught that the best way to predict the outcome of a process is to take periodic measurements and then analyze the data to discover trends.

This is why some managers like to gather numbers like lines-of-code, percent-of-task-complete, and number-of-bugs per unit/developer/time-period/etc. And this is why managers don't like non-quantitative estimates or descriptions of progress.

Developers generally think these measurements are not useful, as they seem to have nothing to do with actual productivity. But the development community has not been successful at finding better ways to predict outcomes.

Do managers understand that measurements do not come for free? Every meaningful measurement incurs a cost to the team, slowing down progress?

Yes, good managers do know this, and consider the cost to be worthwhile. Bad managers do often collect useless measurements, but most measurements are pretty easy/cheap to collect. The real problem is when managers misinterpret or misuse the measurements. For example, if a manager says "We need to double the number of lines of code produced per week", or "I want ten bug reports to be closed by the end of the day", then that is easy for developers to do, but it will have a negative impact on team productivity.

See also SoftwareMetrics, PercentCompletedMyth, PerformanceIndicators, EstimationWoes, HelpYourManager, DeathByScheduling, ProgrammingAintManufacturing

CategoryMetrics