Project Papercut
You may be familiar with the phrase “death by a thousand cuts” or variations on that. You may not know that it has a gruesome origin.
Lingchi (Chinese: 凌遲), translated variously as the slow process, the lingering death, or slow slicing, and also known as death by a thousand cuts, was a form of torture and execution used in China from roughly 900 CE until it was banned in 1905
Lingchi—Wikipedia
The modern version is sometimes called “death by a thousand papercuts” and does not result in actual death but perhaps the death of a product or company.
I couldn’t find agreement on what the phrase means in modern times, so here’s my version.
Let’s say you have a product and you are putting out new versions every year. Issues get reported and are prioritized. For obvious reasons, the most serious issues are more likely to get fixed, leaving a number of small issues that didn’t bubble to the surface.
The problem comes when these small issues start to pile up. The quality and polish of a product start to decline even though you continue to dutifully fix things based on priority.
Enter: Project Papercut
Having worked on a lot of projects that went through multiple new versions, I know quite well the phenomenon of death by a thousand papercuts. I experimented with something I called Project Papercut to try to tackle some of these small issues that piled up.
The key here was to identify clusters of papercut bugs. If a feature of a product or a view in an application just had a couple papercut bugs, maybe that was not such a big deal. But what if the number were 20, 50, 100?
What I did was identify large clusters of bugs in specific areas. For example, if it was a web browser, perhaps there was a cluster of bugs purely in the passwords preference pane.
Then, I would create a brand new bug with Project Papercut in the title and include and relate a list of all the bugs in that cluster. The idea was that it was easy to dismiss bugs on an individual basis as less important than other bugs that need fixing, but hard to ignore a bug with 50 related bugs.
An added benefit here is that it’s a lot easier to tackle a pile of bugs in one area than it is to tackle them piecemeal as they end up in your queue. So it’s a win for efficiency as well.
So you’re probably realizing that fixing a Project Papercut bug means NOT fixing one or more other bugs. But the key point here is that this Project Papercut bug be prioritized above some bugs purely due to the cumulative effect of all the related bugs.
If the end result is virtual death, isn’t it worth fixing a lot of the papercuts?
Note that I did try this on one project and did have a minor amount of success, but that was without any buy-in from anyone else, so I considered that to be a positive result.
