Often times we spend our time coding by looking for ways to make complex logic simpler to handle. Sometimes it requires you to find commonalities between different concepts that are held together abstractly. We usually figure out some sort of pattern to fit our solution. Patterns come about from understanding a complex problem in a suitably simpler way.
However, there are cases where complex logic can’t be patterned into something suitably simpler. For a recent client, we’ve had cases where logic that seemed simple conceptually, actually became quite a hassle. During production, we found many weird cases…(e.g. “If the user happens to do this, then do we do X or Y?”). There happened to be a whole lot of “if-the-user-does-this” scenarios that weren’t self-evident when we first decided to implement the solution.
The problem manifested in code. A bunch of untethered conditions rendered a few different, and potentially disputable, results. In the end, it was a problem that couldn’t be resolved by finding some convenient design pattern to solve it. What we realized is, if it’s this difficult to solve in code, it must be as difficult to understand what’s going on as a user. We ended up creating a much simpler solution, getting rid of a ton of the “what ifs” by just getting rid of this particular piece of functionality.
So, the next time you stumble upon functionality that seems uncannily difficult to implement, one option may be just not to have it. It will probably benefit you and the user.