[lll-o-lll]

Yes you can do it, yes it can work. However as with all things there is nuance. This is a scheduling problem, and just like with a cpu scheduler there are degenerate cases you may need to avoid/handle.

Two problem cases likely to pop up.

1) Lots of fixing when a bigger refactor is required. A poorly written area of code, or a poor design, may be causing high churn and wasted effort. The solution I’ve found to this problem is to track defects by code area and review once metric exceeds heuristic.

2) A team choked on defects only for a long period of time. This obviously has many negative side effects. It tends to happen in really important component and require most experienced developers. Any new starters run for the hills when a team gets into this state, therefore compounding the issues. The solution to this (though this is just my opinion), is to never allow 100% of time over [fixed interval] to be spent on defects. No more than 50%. The bugs will still get fixed, just take longer, and new development is still happening.

Overall though, I think a “defects first” approach is the right one, just have a plan for these negative cases.

[tagspace]

Really good point about bug fixing affecting engineer morale. Super important.

One (arguably positive) side-effect I'm wondering might be possible is that: if bugs are always prioritised first .... and engineers are often very creative at solving problems .... will they perhaps come up with creative ways to reduce bugs in the first place?

Or, it might go all wrong -> and we create a dangerous culture of "swallow that exception" :D