4 ms·
> In other words, in the absence of RoI measures, the percent of engineering time spent on value-add activities is a pretty good proxy for productivity. It's a
by asdfman123 2y ago
> In other words, in the absence of RoI measures, the percent of engineering time spent on value-add activities is a pretty good proxy for productivity.
It's a lagging indicator of productivity. If the team is consumed with fixing old bugs, it means that teams weren't actually that productive years back and were instead just exchanging "results" for technical debt.
Instead of creating a perverse incentive to create messes, what if they did something like create a ratio: "60% of work is new features, and 40% is maintenance"? And if maintenance becomes all consuming, could they look back and identify the problems with previous launches?
- DenisM 2y agoDid that ever work for anybody? It’s an obvious idea, someone must have tried it by now.
- weinzierl 2y agoNot sure if that is what you mean, but at Microsoft they have the *Bug Cap Formula, which is: Bug Cap = # engineers * 5 If the bug count exceeds the cap at the end of the sprint, the next sprint is used for bug fixing only.
- iteria 2y agoI absolutely love this idea and I will be lobbying for this going forward.
- SenHeng 2y agoSeems easily gameable by simply not reporting any new bugs.
- dllthomas 2y agoMy impression is that, at a place like MS, bugs are often reported by a separate team accountable to different metrics.
- asdfman123 2y agoThat works for consumer facing bugs, but a whole lot of them are found by devs.