I've been thinking recently about patterns that lead to good software. Not necessarily design patterns, but any sort of pattern.
One that I've thought of (that likely has been documented elsewhere) I call "application begets framework". This pattern basically states that all things being equal, great frameworks emerge from concrete applications, rather than being created out of the blue. A few examples:Ruby on Rails
- While various Java- and .NET-based web application frameworks have muddled along for years, Ruby on Rails
in just two years has achieved massive mindshare and (as far as I can tell) rapid adoption across the industry. As the wikipedia entry mentions
, it was "was extracted by David Heinemeier Hansson from his work on Basecamp, a project-management tool by 37signals."The Eclipse Platform
- The core Eclipse platform
was designed while partnering very closely with Erich Gamma's team who was building the showcase application on top of Eclipse - the Eclipse Java Development Tools
. Indeed the core platform was so strongly influenced by JDT (and the basic requirement to be an extensible IDE) that later, for version 3.0, the Eclipse team had to perform a major refactoring to separate a generic "Rich Client Platform" framework from the IDE-specific concerns.
I'm sure there are other examples but these are the best two that I can think of.
I believe there are two basic reasons why good frameworks must be extracted from real applications rather than vice versa:
Concrete to generic
- People are better at solving concrete problems than providing generic solutions for undefined problems
- Constraints on design are good
I'm not a student of the human mental process, so this is just based on my experience and observations of software projects; people generally tend to succeed when they are focused on implementing a set of very real user scenario, preferably with the users providing rapid feedback. Occasionally you see parts of the code becoming somewhat redundant, and at that point it's relatively easy to generalize the code into a simple library or perhaps something framework-y. This also comes back to the basic agile mantra "you ain't going to need it". How many thousands of hours have been poured into uber-flexible, generic design patterns, with no particular need in sight?
Another benefit of beginning with concrete problems is that you may actually fail several times until you find a solution that works. But each time you fail, you learn something about the nature of the problem that you can take into consideration if you want to generalize things later. If you start off general, you may stroll very far down hopeless paths but never get the concrete feedback of unhappy users or code smells until after you've spent many hours and dollars on the hopeless design.Constraints are good
go down interesting but ultimately low-business-value design excursions keeps you focused and keeps you learning about things that work.
As I write this, I realize that I'm just making many of the agile arguments in a particular scenario, but still it's worth thinking about next time someone asks you to consider a fancy new framework - just ask how it came into existence and who you can talk to who's used the framework successfully on a project similar to yours. If you get a blank or nervous stare, be wary.
Finally, it would be interesting to discuss how this principle is being applied by the Jazz project, but I'll wait until after programmers and the marketplace have a chance to judge its success.