Re:Ask HN: How do you decide which bugs to ship?
by ggeorgovassilis on Saturday November 19, 2022 @01:57AM
(#33667749)
As a baseline: bugs discovered in production were already shipped, so I'm supplementing your question with "which bugs to tolerate in production".
1. impact in $ terms (to keep things simple, I'm implying a mapping between loss of reputation, loss of opportunity, legal troubles etc. to money): do we lose more money by leaving or removing the bug? Removing a bug might mean disabling a feature which generates income. Removing a bug might mean disabling a feature for the downtime of which we pay contractual penalties. Removing a bug might mean extra effort.
2. workarounds: maybe there is an affordable workaround, eg. running a script periodically which corrects wrong entries in a database or showing users a message how to work around the issue themselves or explaining an odd application behaviour.
3. synergies: maybe there is a good reason to ship a bug because we learn something about the system. Eg. I once took over, rather hastily, a tech lead job where my predecessor left on very short notice. He had built a proprietary, undocumented deployment automation system to work around organisational slowness. When I had to deploy a new version of an application (which was a complex process as it involved several teams and needed to be planned sufficiently ahead of time), I knew deployment would fail, but I chose to do it nonetheless in order to learn more about the deployment system through observing how it behaved during a deployment.
1. impact in $ terms (to keep things simple, I'm implying a mapping between loss of reputation, loss of opportunity, legal troubles etc. to money): do we lose more money by leaving or removing the bug? Removing a bug might mean disabling a feature which generates income. Removing a bug might mean disabling a feature for the downtime of which we pay contractual penalties. Removing a bug might mean extra effort.
2. workarounds: maybe there is an affordable workaround, eg. running a script periodically which corrects wrong entries in a database or showing users a message how to work around the issue themselves or explaining an odd application behaviour.
3. synergies: maybe there is a good reason to ship a bug because we learn something about the system. Eg. I once took over, rather hastily, a tech lead job where my predecessor left on very short notice. He had built a proprietary, undocumented deployment automation system to work around organisational slowness. When I had to deploy a new version of an application (which was a complex process as it involved several teams and needed to be planned sufficiently ahead of time), I knew deployment would fail, but I chose to do it nonetheless in order to learn more about the deployment system through observing how it behaved during a deployment.