Do Papercuts Matter?

"papercuts" is a very poor metaphor for this. In the real world, a cut from an edge of a sheet of paper is surprisingly painful (and sometimes briefly a little scary that something so innocuous can cause such injury and pain!), but the body heals the cut in 24 hours or so with no conscious effort. In the software world, one will keep bumping into the defect while remains, and there is no guarantee that it will ever be corrected.

I view it differently. It's not that papercuts don't matter, it's that people tolerate papercuts when there is no viable alternative. Glitchy software with maddening defects is evidence of lack of competition. If a competitor was to offer a product that didn't have the defects but was able to accomplish the same real goals, they'd quickly take over the market. Failing to fix these annoyances shows that you are not worried about competitors. Sometimes this is a good business strategy, sometimes it will be your downfall.

They matter to builders that care. While software may deliver value, and the business makes money at this moment in time, a disregard for quality over time would create an environment that pushes out builders that care. And when you have people building product that don't care, it's hard to argue they'd care for the customer either. The slippery slope argument, I know. But "how you do anything is how you do everything."

That said, the surface area for any product is huge. It makes sense to prioritize paper cuts that have ROI. Otherwise, you'd never ship. And it is fundamentally true that customers buy and use because it gets their job-to-be-done finished, despite the paper cuts they'd have to wade through.

But like our most closely-held ideals, we may never reach them, but it doesn't mean we should stop trying entirely. Besides, once they find an alternative, or a competitor becomes viable, they'll switch. Paper cuts don't matter, until they do. It's a debt of another kind, where the piper will always come knocking eventually.

I remember when Canonical did a lot of work to fix 'papercuts' in the linux desktop, and they used that term because there was a lot of 'small' bugs that really added up to make the whole thing a pain to use. Especially at the time people were advocating desktop linux as better/more stable than windows but the reality was that for many common tasks you would run into brokeness (audio glitches, wifi problems, etc), but many open source devs saw these bugs as 'minor' although they had an outsize impact on the user experience.

Software "papercuts" work like an abrasive to users. They more they are, they more dread it becomes to use the software, especially if they have to because of work.

When a competitor comes along, you know where the users are going.

But "papercuts" is a weird name. They are bugs. Bad bugs but not bad enough that the author wants to fix them.

The author has come to the dark side. I’ve long advocated that paper cuts don’t matter. I don’t even think of fixing them unless it’s very cheap and safe to do so. Both cheap and safe are key. I’ve seen people fix paper cuts to only introduce a major issue in the product.

Now if it turns out that your highest priority issues are now just paper cuts, then congratulations!

It's all about the elasticity of demand. That's why software that one must use - perfectly inelastic demand - is usually the shittiest, such as government software and corporate crapware. Inelastic demand means that the supplier has no incentive to decrease cost for the consumer (annoyance is an indirect cost). Elastic demand means the supplier benefits from a decrease in cost, because it results in more units sold.

People learn to tolerate minor bugs in software because most software is buggy. If I became upset at every minor (or even major) bug I encountered in day-to-day life, there would be no time to do anything else. On rare occasions I get blocked enough to track down and report/fix the bug[0], but mostly I just try to find a workaround and carry on toward whatever my original goal was.

Even if every bug were to be fixed, one would be frustrated by behaviors that are clearly intentional but stupid, usually because someone tried to over-simplify something[1], hack in a "helpful" shortcut[2], or has aesthetic preferences against supporting complex use cases[3].

Finally, beyond those two great lakes of bugs and bad ideas, we come to the endless ocean of missing minor functionality. The comic reader that lets page order be swapped for manga but doesn't change which arrow "next page" is bound to; the web browser that doesn't allow translating a page unless its language heuristics get tickled in the right way; the mobile keyboard that couples auto-punctuation with spelling correction.

It's like the joke about wine snobs -- if you don't know much about wine then most wines taste fine, but if you take a wine appreciation course then you'll never be able to enjoy it again.

[0] three weeks ago: https://bugs.ghostscript.com/show_bug.cgi?id=706551

[1] A lot of GNOME's applications fall into this category, for example its "Document Scanner" vs xsane, or "Music Player" vs Rhythmbox/Banshee.

[2] two weeks ago: https://mstdn.io/@jmillikin/110211856191257399

[3] I am annoyed daily by crates.io lacking per-user namespaces, and the primary objection to adding them seems to be driven by a preference for single-token package names.

> The realisation: I keep paying for and using software even though it has papercuts.

Because there is no viable alternative. If the two pieces of software offer same (or at least similar) features, one that has less "papercuts" will win, no? To put it simply, if there is an alternative, we use software that is _better_ (having less papercuts is one way of measuring, I guess).

In what context?

To the artisan/craftsman writing code for their own pleasure? Yes!

To FAANG scale companies in their primary user interactions? Absolutely! (The big guys measure substantial revenue impact from almost-imperceptible latency differences, for example.)

Always, in every context, over every other thing you could be doing, without prioritization? Of course not.

I think the “always fix paper cuts when you hit them” mindset could be great in some places. You would not last long as a startup if that was your philosophy.

Papercuts are worthy of special consideration though, because if you ignore them, they can in aggregate build up to a substantial drag. Just make sure you talk to your users, measure your funnel, and watch them use your product. If they are delighted, you probably don’t have too many papercuts.

Bugs don’t matter until they do. I once worked at a SaaS firm with atrocious reliability- eventually the NPS surveys said that was the top issue. Surprisingly it receded to issue #N when reliability went to “we don’t have a weekly outage”. This was a multibillion dollar SaaS.

My two cents is that paper cuts hamper productivity more than anything else. Even if customers don’t care about monthly downtime/small gotchas. The dev team will have to spend time thinking about it and dealing with it. A company with a 2 hour build, and multi day test cycle will naturally have dev productivity near zero.

Papercuts might matter, but there's a time and a place for everything. If you have limited resource-constrained, and the choice is between solving minor issues or driving the product forward, do the latter.

That doesn't mean you shouldn't be improving quirks and annoyances in the product, but such things should be proportional to work that delivers value.

At some point, it can devolve into perfectionism and grind all meaningful progress to a halt.

Maybe every quarter (or some other time period) have a timeboxed story to search and destroy these papercuts. One variation would have the story opened and collecting papercuts over a period of time; then when it hits a certain number, the story gets bumped up in priority.

I suspect too many of these papercuts might leave a door open that lets bugs in.

Papercuts and other bugs/UX-issues do matter, but as with anything it’s contextual.

Is the application providing more value than the issues detract? Are there enough issues that the balance is no longer in favour of using the application?

That’s why the phrase is “death by a thousand papercuts”. A single one won’t push a user away, but many of them combined will.

Do they matter? I'd argue that yes, they absolutely do.

They might not make people refuse to use a piece of software, or actively seek out an alternative - but they're certainly going to result in users having a lower opinion of that software, and make them more likely to take notice if an alternative happens to come to their attention.

related from Nassim Taleb: if in an expensive area you need too choose between a shoddy looking restaurant and a beautiful stylish one, go to the shoddy one, because probably the only reason it can survive in that area is that it has great food, the stylish one could survive just because people go there for the atmosphere.

Related concepts: The Brown M&M’s Principle (Papercuts could be perceived as indicators of overall quality). Broken Window Theory (Papercuts may communicate poorer quality is acceptable). In practice it's a question of priorization and limited resources. I recommend setting aside some time to fix them.

Referencing from The Pragmatic Programmer book - broken windows. Just like having broken windows in a neighborhood would slowly bring down the quality of the block I believe the same will happen to software if there are the same glaring issues popping up that are ignored.

As someone who is team anti-papercut, Jira I think is a good example. Chances are if you use jira at work you know many people who hate jira, devs complain about it all the time, stuff that seems like it should be 1 step takes 3, and every so often someone proposes an alternative. It sticks around and dominates the space because it does solve a lot of problems and is flexible enough that it becomes entrenched in your teams workflows and for any give papercut you can generally workaround it and ignore it. Still if it didn’t have these papercuts people wouldn’t even consider replacing this behemoth with something else and I am sure there is a fair amount of user churn due to these issues, e.g. dev who hates jira starts a start up and vehemently opposes using it due to previous experiences.

This is a case where thought experiments based on your own assumptions just aren’t very useful.

It’s very way to end up arguing with straw men about made up categories.

What you define as “paper cuts” is probably very arbitrary and would differ significantly between individuals. It only makes sense in the context of an existing backlog of issues that is properly groomed and labeled. Otherwise you may as well just call them “pet peeves” instead. It’s totally subjective.

So whether they “matter” or not is really unanswerable outside of that context, and frankly not very interesting within that context as well. If they mattered they would already have been fixed…

If your product solves a real problem your prospective customers are having, minor rendering glitches don’t matter.

If your potential users don’t really see the benefit of your app, no amount of pixel-perfect rendering is going to help.

I have a reverse corollary of this, which is: As I do/use things that are useful/interesting despite of their papercuts, then if I don't do/use something because of perceived "papercuts", they are probably not really the reason.

Examples are not recording music because my audio interface is a bit too laggy, or not taking photos because my camera lens is a tad blurry in the corners. The real reason is that I'm not motivated / inspired enough and like to blame the "papercuts" of my gear.

Of course papercuts matter. They aren't showstoppers, but every one makes the software feel less trustworthy, less reliable, less solid.

If there's only a small number, that's fine. Past a certain threshold, however, and the software will be seen as undesirable no matter how good it is at allowing the user to accomplish what they need to accomplish.

I've noticed that paper cuts expose some of my subconscious biases. When Windows does something braindead, I shrug and move on. When Linux does the same, I get a certain sense of inferiority and feel an urge to rant about muh Linux desktop. Maybe it's a matter of low vs high expectations.

To author - what a missed opportunity to use "superglue" as a healer and metaphor. Temporary fixes are probably good enough - these cuts will be re-absored by another team later, anyway or washed away by organizational/product learning.

"Papercuts" are the reason why many people dread using software, and mostly only do when and where they must. The experience is just unpleasant. It's really death by a thousand cuts.

Do you think the Windows lock screen will ever let you start typing your password right away rather than throwing all your inputs away for a random amount of time up to several seconds?

I was thinking a paper cut meant something like rough-looking code that works. If we are talking about bugs, that's a different story. Some bugs are more important than others.

Life is full of papercuts. You just have to choose your battles wisely when taking them on, whether it’s software or a creaky floor in your house or anything else.

The author has missed something vital (and to be fair while HN might not be the right demographic for arguing it I think most of us understand it intrinsically):

The difference between and inconvenience and a barrier is typically in the knowledge level of the user.

For example years ago I found that I understood how devs built enough to know all the common UI/UX patterns. If I needed to get to some buried functionality out of a piece of software I wasn’t familiar with I could usually find the control in less than 3 seconds whether it was a tiny button or a menu item 4 layers deep.

But hand that same task to a user without the experience needed to reach that level of understanding, and that becomes a barrier that can slow them down or halt them entirely. And here’s the issue: usually those are your ideal customers. The ones you’re building for, the ones that pay you, and the ones that you want to sing the praises of your software.

TL;DR: Keep your perspective in check when developing: is it a “papercut” because it’s insignificant to everyone? Or because you have thick skin?

I think coming up with terminology for a blog like this is stupid. In some years the author is going to write an aside that goes something like this: (Papercuts is a term I coined ten years ago on my blog)

and here I thought I'd read about paper and blood