If we assume, as a thought experiment, that the amount of pain associated with the lifetime of a software project, inception to obsolescence, might be a constant, then there might be merit to the following observations:
1. Using a Frame Work, any Frame Work, is likely to lower the total amount of pain suffered throughout the system's life cycle simply because the Frame Work embodies and soothes the collective lessons (pain) of prior use in a variety of situations.
2. Depending on the Frame Work, you'll have either
- more up-front pain from using a Frame Work that is powerful and flexible and configurable such that, by definition, it takes a longer time to learn it, or
- more back-end pain from using a Frame Work that, in the end, wasn't powerful or flexible or configurable enough,
- or both excessive front- and back-end pain, depending on how well you match the Frame Work with your skills and your application (and it's hitherto unforeseen forces of growth and change).
Personal opinion: given the choice, go for the up-front pain in the hopes of having something more flexible and adaptive for future changes. This is why, I believe, many developers opt to write their own frameworks (framework vendors included). Just please (!) beware of being too much of a Lone Ranger.
Contributors: Steven Black
( Topic last updated: 2000.03.26 04:04:36 PM )