Self-inflicted pain: certain costs for uncertain upsides
In every project, there are things I call self-inflicted pains. They are bugs, issues, or complications that arise from a choice that has an uncertain upside and a certain cost.
When designing a webpage, a designer thinks that using a carousel is a good idea. A developer implements the carousel without too much questioning. Now we have issues to deal with, like cross-browser compatibility, accessibility testing, a library dependency, and more code that bloats our JavaScript bundle. Is all of this necessary? Probably not. Does a carousel convert more users or bring more business? Who knows? Does the webpage look slicker? Debatable. Would we have been better off without a carousel? We’d likely achieve the same aim with less work.
Other examples are:
- Horizontal scrollable content on a webpage
- Scroll-driven animation and content
- Using a NoSQL database for everything
- Using the newest framework or tool
- Adding analytics (and the cookie banner that comes with it)
- Using dialogs and modals
This applies to any project, not just software projects. Choose a luxury object instead of a sturdy all-rounder, and then you’ll stress about scratching it, losing it, or having it stolen. Was that choice worth it?
How do you spot potential self-inflicted pains? They usually sneak into things that sound trivial and aren’t critical. Sometimes they hide in decisions made too quickly without thinking about the externalities or unknowns. If nobody can make a strong case for it, and a simpler approach exists, it will probably cause future issues.
Avoiding future self-inflicted pains saves time and mental energy that’s better spent on what matters.