back
6 comments
Our PM would identify and prioritize customer requirements (so creating a foobar in the UI is P1, renaming it is P2, showing a loading spinner is P3, etc). Then our QA tester would “bug bash” and assign priority to bugs according to the requirement it violated. We had a policy of “GA releases cannot contain any >P2 priority bugs” or similar.

This system worked well with a technical PM, proper release planning (allocating time to test and fix bugs), and the autonomy to bend the rules a bit in either direction (e.g. “this bug is technically P4 but it’s embarrassing and will be easier to fix now”). At times we had an additional ongoing policy of pulling several non-blocker bugs into each sprint to ensure they weren’t neglected.

Step one sort bugs into categories. 1) Critical failure ... 10) typo in help page no one reads. Obviously #1s need to be fixed. Usually anything that yields bad press needs fixing. Things that have easy work arounds are acceptable. This is balanced against competitive edge. If an opponent will grab a major market share if you do not ship now .... I guess it always gets down to dollars. Hard part is determining value of reputation - everything perfect (which it will NEVER be, verses ever getting the product out.
They don't. They ship when the top brass wants them to. The developers can fix them later by working 80+ hours a week.
The Silicon Valley way:

1. Start working on a brand new project.

2. Optimize for delivery and thus write garbage code.

3. Get recognized/promoted/a big bonus for delivering on time.

4. Start working on a new project or leave to a new company while others are forced to deal with your mess.

5. Rinse and repeat

Image of Kayode Ewumi grinning and pointing to his temple

You can't ship a bug that hasn't been identified as such.

What is this amateur hour? Just don't create the ticket