I liked the article for clearly naming certain common problems with frameworks. And I see the benefit from "stunting" frameworks to prevent over-complexity.
The main problem with unconstrained frameworks is that pressure to grow is not adequately countered by pressure to remain easily learnable, usable and tailorable.
However a "stunted" framework is also frozen and cannot be improved, even if the improved version would still be small and simple.
What if we create constraints to contain growth and complexity, buil in to the project requirements? For example, add these requirements (with suitable numbers for C, M, H) to the framework charter:
1. The framework will consist of no more than C classes with a total of M methods.
2. The framework will be learnable by a new user in no more than H hours.
3. All files (source, makefiles, tests etc.) required to modify and build the framework will be included in each release.
4. All permissions and licenses required to modify and build the framework will be included in each release, and will continue for a reasonable (fairly long) period, even after subsequent versions are released.
Testing requirements #1 and #3 can be done automatically. Testing #2 is simple (though not automatic!). Testing #4 might require legal review.
When C, M, H are small numbers, this corresponds closely to the definition of a 'seedwork'. Larger frameworks would need larger C, M, H, but still need constraints against over-complexity and bloat.
One advantage of this approach is that the framework can improve within its scope by increased elegance, trading features (adding better designed or more valuable features while deleting others), bug fixes etc. It also helps the designer remember that simplicity and compactness are part of the design goals, even in release 1.
If a user is happy with release R (or if release R+1 is incompatible with a user's application), I don't see much problem with releasing new versions because users still have permission to continue using their prefered old version.
Flat View: This topic has 15 replies
on 2 pages
[
«
|
12
]
Previous Topic
