I saw an interesting blog post from thoughbot yesterday, and it reminded me of an older talk that I saw years ago. To quickly summarize:

Decisions can be thought of as either one-way or two-way doors. Two way doors are easily reversible, and low risk. Once you step through into the next “room”, it’s easy to see whether you like it or not and go back. However, a one way door is more like an emergency exit in a line at Disney World. You’re welcome to get back in line later, but you can’t get back all the time you put in earlier, you just have to start over.

Obviously, when building software, or really any time, low risk options are preferred, and the only reason to go with the high risk option is a really significant reward for taking that route. That said, what if we could take that high-risk option and give ourselves a way out? This is where I remembered a talk by Gary Bernhardt where he was talking about creating clear boundaries in code. His focus was mostly on separating core logic from messier mutable functions so that testing is easier, but the same logic can be used with bigger decisions to separate out high risk areas of a system to protect the rest.

One of the highest risk parts of most applications are the integrations with external systems. Sometimes these provide high value, and contribute to the core functions, but they are managed by another organization, and potentially an organization with differing long term plans.

In these cases, my preference is always to build the integration out in a way that treats the functionality generically from the application side, but then the other side of the interface can deal with the external system as natively as possible. By keeping all of the specifics out of the core system, the goal is to reduce the vendor risk with as little overhead as possible. Going back to the original metaphor, this is a bit like adding a doorstop as you pass through a one way door to make it act like a two-way. It might not always work, and there’s a little extra effort, but you have a much higher likelihood of being able to turn around and try something else if your first option doesn’t work out as well as you hoped.

https://thoughtbot.com/blog/one-way-vs-two-way-door-decisions

https://www.destroyallsoftware.com/talks/boundaries