What about the unhappy path?
When we create a feature, we first write code which makes the happy path succeed. I think in most cases the happy path is handled around 80% of the time. But what about the unhappy paths?
What if a certain unhappy path occurs only once a year? Are you going to make sure that path is handled correctly by spending time to write that code? Or do you, as a developer, let the unhappy path fail and let the support team fix whatever is handled incorrectly?
If you don’t know if a certain unhappy path will occur often, you can decide not to implement it and measure the times it occurs. If it happens like once a year, the costs of implementing the unhappy path by a developer are probably higher than letting the support team fix it once a year. But if you’re getting errors every day, it’s probably more valuable to handle that unhappy path in code.
After creating a list of all possible unhappy paths you can decide per path whether you’re going to handle it in code or not.
As long it is an well-informed decision.
Addition: A collegue of mine replied on Twitter: "What about context? Is it wise to let the unhappy path fail in a certain context?". I think it's a good addition. Depending on the context you can make an even better decision.