I believe that the topic of “how to use software frameworks” is one of the most complex and problematic in the world of software development. They are seductive because they offer the promise of making rapid progress, but they are dangerous because they tend to introduce a pretty rigid view of the world, which can cause problems if the architecture you want isn’t well aligned with the framework, in the best case you will spend a lot of cycles trying to bend the framework to your will or in the worst case, you will fail to produce the architecture you really want because the framework defeated you.
These are my basic biases towards frameworks:
If I am trying to build an application fast and I don’t care about maintaining the code for a number of years, I will eagerly use a framework that seems like a good fit.
If I am writing new code that will form the basis of a product family that will be used for years, perhaps decades, I will never use a framework (though I will use libraries). It is highly likely that in the course of writing my own code, simple custom frameworks will emerge, but they will not assume that they “own the world”; in other words not monolithic.
And then of course between these two extremes (quick and dirty application vs. product family foundation) it gets a bit fuzzier.
I believe (based on only anecdotal evidence) that very good developers who are building software that will have to endure for years tend to create their own simple frameworks rather than adopting existing framework.
Or using my friend Pat Mueller‘s words: “Every framework is evil. Except mine.”
Pingback: using reflection in OSGi // Bill Higgins' Blog