I just had to clip this somewhere:
When you're solving a problem, you often decide to limit yourself to something that's as specific as possible. When you do so, you usually place awkward limits on developers who wish to use your framework and customers who would use it. General solutions often solve more problems than a specific solution does. There's an interesting side benefit. You can often solve the general problem with less effort, cleaner designs, and simpler algorithms. That's the Inventor's Paradox.
In How to Solve It (Princeton University Press), a book that's quite famous in mathematics circles, George Polya introduces the Inventor's Paradox: "The more ambitious plan may have more chances of success." In other words, you can frequently solve a useful general problem more effectively than a highly specialized one. It's a principle that works often in math. For example, try totaling all of the numbers from 1-99, in sequence. Then, think of it in this way: (1 + 99) + (2 + 98) + ... + (49 + 51) + 50. You can probably solve the second equation in your head. Once you generalize the problem in this way, you can quickly sum any sequence of numbers. The general problem is easier to solve. It works in industry, too, as you saw in my duct tape example.
There are many examples of the Inventor's Paradox in programming. Often, the most successful frameworks are simple generalizations of a complex problem. Apache web server plug-ins, Visual Basic custom controls, and the Internet are but a few examples of simple generalizations. Closer to home, Ant and Tomcat surpassed the wildest expectations of their author, James Duncan Davidson. Both of these frameworks allow exquisitely simple, elegant extensions. You don't have to have the luck of James Bond or the intellect of Albert Einstein to make the Inventor's Paradox work for you. Simply train yourself to look for opportunities to generalize. Start with this list of questions:
What's likely to change?
You can't spend all of your time generalizing every block of code, but you can identify areas that you may need to future-proof. MVC is a famous design pattern because views and models change. It's important to generalize the way you deal with your views so you can change at need. If you intentionally identify and generalize these interfaces, you'll often be much better off. I'm not arguing for more complexity. You are looking for ways to generalize and simplify at the same time.
Is there a different way to solve this cumbersome problem?
When I get in trouble, I usually step back and ask myself, "Why this way?" For example, many open source projects read configuration files as XML DOM (Domain Object Model) trees. Many developers begin to look at configuration as a Java representation of an XML file. It's not. Instead of looking for ways to efficiently lob DOM trees across your application, look for the reason that you're doing so. Maybe it's better to read that configuration file once, and translate it to a smaller set of concrete objects representing your configuration. You can share those at will.
Have I seen this problem before in another context?
Simple generalizations often show up in dramatically different contexts. For example, it took me a while to see that the model-view-controller concepts are not limited to views. You can generalize a view as just another interface. You can apply MVC-like ideas to many different types of services, including persistence and messaging.
In the next couple of chapters, you'll see these principles in action. Spring generalizes a concept called inversion of control and uses a generalized architecture to assemble and configure entire applications—from the database to the user interface and everything in between. Rather than including a stored procedure framework, Hibernate exposes the JDBC connection, allowing users to extend Hibernate in ways that the inventors often never considered.
The Inventor's Paradox represents all that's fun about programming: finding simple, elegant solutions to difficult problems. When you do, you'll find that patterns that seemed tedious in books emerge as new creations. But it's only the first step in allowing for extension.
from...
Better, Faster, Lighter Java
by Justin Gehtland and Bruce Tate
Publisher: O'Reilly
Pub Date: June 2004
ISBN: 0596006764
Pages: 250
p. 130
6.1.2.1 The Inventor's Paradox