There comes a time in software development when enough is enough.

As developers we (I'm not excluding myself from this group) will design and create toolsets called frameworks to support the software that we're writing.  It's natural.  It's easy (usually).  Of course, much of the code we write tends to be specific to a particular problem domain...but that's completely unacceptable.  We must abstract away any hint of specificity and genericize all aspects of our applications.  We then create support libraries that create objects and provide services of some generic, not-known-until-consumed-by-an-application type for some mystical reuse that probably will never happen...but just in case.  Heaven forbid that our framework have any knowledge or insight into what our application will do or how the information might be utilized.  These frameworks then tend to get bloated and so generic as to lose all sense of meaning.

We create frameworks to support some greater project or set of projects.  If new functionality needs to be added to our application it's inconceivable that the functionality should be applied directly to the program.  Rather, the supporting framework should be enhanced in a generic manner such that the program can consume some service provided by the framework to supply the functionality.  Inevitably, the project scope balloons and the framework bloats to support some obscure functionality, further diminishing the framework's usefulness.

As developers we lose sight of what we were originally trying to achieve: the writing of software.  Instead, we like to focus on the innards that supply functionality to our software.  Sometimes that enough - but not always.  Oftentimes, the creation of the framework is too specific.  It would be better if we got down closer to the metal and wrote the supporting code for the framework.  By identifying the services the framework needs to properly function we can add new, even more generic functionality, thereby enabling our framework to support more theoretical applications.

You know, there's really no end to the insanity.  All we wanted to do in the first place is create a simple program.  But we couldn't simply use the functionality already available to us, we had to go reinvent the wheel rather than simply pumping up the tires.  All I wanted was a Universal Hammer.

NOTE: Joel Spolsky's blog post is a great read.  If you write software, read it and take it to heart.