Software Paper Cuts
When software isn’t polished, when it’s full of things that feel like paper cuts, it becomes less joyful and more frustrating. It sucks all the opportunity for delight out of the room.
The more insidious thing about these bugs is that they’re rarely reported by users or caught by automated testing tools because they’re too small to complain about or too obscure to write tests for. Great QA testers can find and file these types of bugs, but they usually flounder at the end of a long backlog of new features. This means that if you’re an engineer on a piece of software, you’re the person who’s best able to notice and fix these bugs. Yes, you might have to convince your boss or your product manager to set aside some time every so often to do so, but I promise your users will be grateful, and your product will improve in meaningful ways if you do.
The most frustrating part of these issues is that they always look small, but they’re so often downstream reflections of a significant architectural decision that will have to someday be reversed if the problem is to be corrected.
The issue with these kinds of things is that they start as paper cuts, sure. But they don’t end that way. A few here and there will inevitably add up over the years to something much worse. You go from paper cuts to a laceration, and then a straight gaping hole in your app.
What follows? The refactor. The ground up rewrite.
