A new path for getting geo::BooleanOps without panics

Last week I stumbled upon yet another case where the geo::BooleanOps trait methods panic. This is highly frustrating since it keeps me from using the code. The reason for this is that I can't let my app crash and I can't even catch the panics with some fancy shenanigans. After countless attempts to create

• a standalone implementation from the ground up (my tip: don't do it. There are infinitly many special cases and you're not smarter than what is already available)
• a safe wrapper around the existing geo::BooleanOps which won't panic

I decided to give one last other idea another try

Implementing falliable geo::BooleanOps

About one year ago I already tried to just "resultify" all the places where the current implementation of the operations in the geo repository can panic. However, back then we got stuck at one place. At some point in the implementation we need to get the result through the next method of the Iterator trait. Since the method has to return an Option<Item>, we thought it would be impossible to make the changes and we gave up. Nowadays I'm a tiny bit smarter though. Although it is a bit hacky, we can just return a Option<Result<Item, Error>> and then make use of the transpose method on Option<Result<..,..>> types to get the desired information through the trait method. After some fiddling, I finally came up with a first draft for the new falliable methods on the old BooleanOps trait. You can find the draft PR here.

It worked fine for my use case. Let's see how far this will go. It finally feels like we're getting control over the problem.

The tails of broken windows

Excerpt from The Pragmatic Programmer

The following is one of the most powerful ideas I've read about so far.

Entropy is a term which doesn't only exist in the physical world. It's also a real thing in software engineering when it comes to the amount of disorder in code bases. Unfortunately the entropy in informatics behaves the same way as in physics, it tends to increase over time. Sometimes we also call it technical debt. Let's take a look at a small comparison that will help us to understand how to tame that phenomenon.

In most inner cities there are two kinds of buildings. Some are beautiful and clean while others seem to rot over time. The question is: why is that? Researchers in the field of crime and urban decay stumbled across an interesting trigger, that can turn a beautiful neighborhood into a abandoned place over time.

It's a broken window.

One broken window, left for any substantial length of time, can instill a sense of abandonment in it's inhabitants. It raises a feeling that other residents who are responsible just don't care about the livelihood which decreases motivation to do the simplest maintanence. So after some time another window gets broken, people start littering, amateur graffiti appears everywhere and serious structural damage starts to manifest. When it gets to this point, the damages reach a point where it isn't even desireable for the owner of the house to fix it at all and the decay continues until the building is a complete ruin.

Why is that? Psychologists have done studies that show that hopelessness can be contagious. Ignoring a clearly broken situation reinforces the idea that perhaps nothing can be fixed, that noone cases and everything is doomed. All these negative thoughts can spread amongst team members creating a vicious spiral. So the one important conclusion from that story is:

Don't live with broken windows

Don't leave "broken windows" (bad designs, wrong decisions, poor code) unrepaired. Fix each one as soon as it is discovered and if there is insufficient time to fix it, at least create a plan and save that somewhere for later. Perhaps you can also just comment out the offending code, or display a "Not implemented" message, or substitute dummy code instead. Take some kind of action now to show you're on top of the situation, that someone cares and to prevent further damage.

Just always remind yourself: "No broken windows".