4 ms·

"If you want reliable software, insist that no new features go in until all the reported bugs have been fixed." That is a massive oversimplification. In fact,

by zaidf 10y ago

"If you want reliable software, insist that no new features go in until all the reported bugs have been fixed." That is a massive oversimplification. In fact, a key job of a product manager is differentiating between critical bugs that must be fixed, bugs that should be fixed but can wait and bugs that don't need fixing in the near term. Otherwise, for any mature piece of software (particular enterprise software), you will be fixing almost an infinite number of bugs that add little value at the expense of critical features that make the needle move. This is one of the biggest lessons I got when working on a decade old enterprise software. At first, I was shocked that our VP of Product put certain bugs in the "won't fix any time soon" category. But now, I see how much more value we'be been able to drive because we decided to ignore certain category of bugs for new feature or other feature improvements. Insisting on blindly prioritizing bug fixes over any thing else does nothing more than satisfy our engineering ego. Don't assume it automatically making the product more useful for the user or driving more value to the company or its customers

lockedoutwhoops 10y ago
Good point that metrics for prioritization are revenue and customer satisfaction. You can cut a lot of cruft when applying these filters.
wpietri 10y ago
You ignore how there got to be an infinite number of bugs in the first place. It's people following exactly the rule you suggest: chase the sugar high of metrics bumps while leaving maintenance for "later". What this misses is that a buggy code base with a lot of technical debt makes it very hard to get anything new done. Worse, because you've spent years teaching people that being sloppy is the way to go, even when they rewrite something or build something new, it won't be very good and will still have a high maintenance cost. Whereas if you follow a quality-first approach from the beginning, you never build up those mountains of technical debt. You can have a sustained pace of innovation that's much higher because you aren't working on top of a garbage heap. And you have people with excellent habits and a good working environment, meaning high productivity and low turnover.

by zaidf 10y ago

lockedoutwhoops 10y ago

Good point that metrics for prioritization are revenue and customer satisfaction. You can cut a lot of cruft when applying these filters.

wpietri 10y ago

You ignore how there got to be an infinite number of bugs in the first place. It's people following exactly the rule you suggest: chase the sugar high of metrics bumps while leaving maintenance for "later". What this misses is that a buggy code base with a lot of technical debt makes it very hard to get anything new done. Worse, because you've spent years teaching people that being sloppy is the way to go, even when they rewrite something or build something new, it won't be very good and will still have a high maintenance cost. Whereas if you follow a quality-first approach from the beginning, you never build up those mountains of technical debt. You can have a sustained pace of innovation that's much higher because you aren't working on top of a garbage heap. And you have people with excellent habits and a good working environment, meaning high productivity and low turnover.