A while back I was at a Facebook developer event, talking about techniques for analysing Objective-C. My summary of the problem was something like “it’s one of those things that works pretty well in the ivory towers of practice but completely falls apart when you try to use it in theory.”
That’s true of many things in building software, but as people who get paid for removing bugs from things we’re all too good at the situations where the theory doesn’t pan out. Problems arise when we report the overly general conclusion: “that doesn’t work” rather than “there exists a condition in which that doesn’t work”.
Often, the appropriate thing to do is to build the thing anyway and extract value from it in the cases where it does work. Most Ruby code is just Java with different punctuation: if you build a thing that can’t possibly work because of monkey patching then build it anyway and 100% (give or take) of Ruby you actually encounter will work with it.
If it were up to programmers we wouldn’t have paper money. You can’t promise to back 10× as much money as you’ve actually got gold to make good on, in case everyone asks for it back. Ah, but what if they don’t?
And even if you find that the edge situations arise too frequently to make the thing you built worthwhile, you’ll have learned something about the problem. You may find a different approach, or even that solving a slightly (or greatly) different problem is what you really want to do.
When someone tells you the thing you want to build can’t work, build it and work with it. If only for the look on their face.
