"you are trying to keep the pain of dealing with these ill-fitting interfaces from spreading throughout your system"
Today's riff is inspired by Russ Olsen's comment above, taken from his wonderful book Design Patterns in Ruby.
Great work now leads to more work later
If you build an incredible app or lib, folks will be writing interfaces^ to it for a long time. APIs are powerful when they have grown stable enough to become a reliable part of (information) infrastructure. But along the development cycle, builders are continually challenged to construct new interfaces for specific data formats*, or port the existing software to new platforms. In fact, the more useful the tool, the more this interface work will be desired or needed.
Maslow's Hammer
When it comes to software design, a common description of utilities is that they represent tangible tools. Developers of each framework work hard to abstract the essence of what their tool does by minimizing assumptions about data that it processes. Often they succeed so well that their tool can be used in many situations that it wasn't originally intended for, yielding both positive and negative consequences (there's more than one way to do it).
Now consider the effect of a common cognitive bias on the process of software design. The exposure effect is to favor an option based on one's familiarity with it. More specifically the law of instrument captures this decision making pitfall:
The concept known as the law of the instrument, Maslow's hammer, or a golden hammer is an over-reliance on a familiar tool; as Abraham Maslow said in 1966, "It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
If like myself, you are digging deeply into web development from an application perspective, it's tempting to continually reuse the same framework whether it's Zend php, Python/Django, or Ruby on Rails. In practice this leads to heavier, more bloated interfaces which can confuse new users as well as hinder your own reuse. Packaged along with familiar structures (generally a benefit) a framework may have an ever growing variety of plugins**. Unwieldy complexity is the byproduct of years of tool reuse without periodic consideration and careful code refactoring.
Notes:
^= I've got interfaces on my mind this week while learning about the differences between datamapper and active record (models), the google app engine and more general platforms, and Rails and Sinatra.
*= better to get third parties to port their data to an accepted standard
**= As much as I enjoy Wordpress plugins, they are highly susceptible to breakage with every core framework upgrade