Maybe the worst carryover from the economic age is the notion of time monitoring. Managers really feel a robust urge to measure one thing, and “time spent on a activity” turns into a robust shiny object that’s onerous to withstand. Thus, groups are sometimes required to trace the period of time it takes to repair every bug or full particular person duties. These instances are then in contrast between builders to supply some measure of productiveness and a way of figuring out success. A decrease common bug-fixing time is sweet, proper? Or is it?
The worst metric of all
Time monitoring of software program builders is — in a phrase — terrible. No two bugs are alike, and inexperienced builders may be capable of rapidly crank out fixes for a lot of straightforward bugs whereas extra skilled builders, who may typically be given the more difficult points, take longer. Or possibly the junior developer is assigned a bug that they’ll’t deal with? Worse, time monitoring encourages builders to strive gaming the system. After they’re worrying about how lengthy a activity may take, they might keep away from those who may take longer than the “estimate” and all method of “non-productive” actions.
Don’t now we have to confess that there isn’t any strategy to decide how lengthy any explicit software program work unit ought to or will take? Having to account for each minute of the day merely creates unhealthy incentives to chop corners. It can also make a sensible, succesful developer really feel anxious or involved for taking “too lengthy” to resolve difficult issues that have been presupposed to be an “straightforward, one-line change.”
