At the end of Indecent Proposal, there is a lovely scene. Demi Moore is with Robert Redford, who is realizing that she's not happy with him, and that she wants to go back to her husband. So Redford starts bantering about how many women he has been with, and how little they meant to him, present company included.
But he doesn't mean any of it: what he's really doing is giving her an honorable way out by allowing her to be the offended party, and she knows it. And as she leaves him, you can see that she's grateful for this last kindness, which allows her to keep her dignity.
I wish all breakups were this civilized, especially in the world of software. Too often, we make enormous commitments, and when things go wrong, as they so often do, the consequences can be devastating. The database company you so carefully selected goes belly up. The framework that's a central part of your architecture disappears. And you find yourself up the proverbial creek.
If your project depends on a third-party software package, you have to consider what will happen if that package becomes unavailable. We all know that this could happen for a wealth of reasons:
- the company goes bankrupt
- development stops or peters out (not uncommon for open-source projects)
- there is a lawsuit over a patent
- the package's requirements no longer match yours
- the package is evolving in a direction that is incompatible with your goals
- the price becomes unaffordable
And yet, in development plan after development plan, you see very little about this topic.
As software vendors, of course, we're in a seemingly awkward position: we should like people to be locked in to our products, but at the same time, we know perfectly well that it's foolish to prevent people from moving off. Just like in real life, if you really love someone, you have to let them go if they want to. Hanging on too long is short-sighted, selfish and ultimately bad karma.
I was reminded of this recently while looking at Spring's Roo project, which is an intriguing approach to automating certain development tasks. The creators of Roo were kind enough (or forward-looking enough) to think of the breakup problem, and they have included an elegant solution: if you wish to get rid of Roo, it will generate all the code necessary to replace itself. Of course, you will then stop enjoying all the benefits of Roo (by definition), but this makes it possible to go on by yourself.
This is an excellent approach to a vexing problem, and it should quell many questions about adopting a new technology. Worst-case scenario, you can always chuck it, and you'll be no worse off than you were before you started using it.
-- Max Tardiveau, October 14, 2011