I’ve run into a few problems recently that I felt had a common denominator that I couldn’t quite put my finger on. When it clicked, I thought I’d write something down just to solidify the idea in my head. I call it somersault problems. There may be a more formally (or colloquially) defined term but I am not aware of it, so this is what I’m going with. I also considered uphill bicycle problems, but somersaults seemed more fun.
The gist is: the problem is of such a nature that if you start, you better commit to solving it fully in one go, or you are better off not starting at all. The progress indicator is one bit, not a floating point or even discreet number.
Normally, the best way to attack any problem is in a divide and conquer-fashion. Solve as little as possible, reassess your situation based on the feedback received and repeat.
Every now and then, however, you run into something where this strategy can’t be applied. You wanted to introduce a tiny bit of const correctness in your new code but because your wonderful programming language has proper transitivity, the compiler refuses everything until you’ve changed practically the entire code base. Or you thought you’d just update Webpack to the newest version, but found that it came with a slew of derivative dependency updates that now require you to fix all kinds of weird new bugs.
These situations are bad because no improvement can be obtained before everything is solved, but they do have a redeeming quality: they can be rolled back. Git saves us, we have the option to realize half-way that we’d rather not bother. The worst type of somersault problem is the one that can’t easily be undone if half-way completed. Like destructive database migrations in a live system. Or moving to a new house. Or changing the name of the company (which is, in my experience, an order of magnitude more involved than one would imagine).
Should you avoid problems that are somersaulty? Well sure, if you can. Or not. Sometimes, you just can’t. I am hoping that with this term, I will be more likely to spot this trait in a problem and at the very least be aware of the additional stress it will put on your team while blocking the pipeline. And see if there are ways to alleviate the problem by “prepping the ground”. For instance, you could update the Webpack dependencies first. That way, you might be able to reduce it to a mere roll problem.
Top comments (0)