The Artima Developer Community
Sponsored Link

Weblogs Forum
Stunting a Framework

15 replies on 2 pages. Most recent reply: Apr 9, 2004 4:15 AM by Daniel Knierim

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 15 replies on 2 pages [ « | 1 2 ]
Daniel Knierim

Posts: 1
Nickname: calouro
Registered: Apr, 2004

Re: Stunting a Framework Posted: Apr 9, 2004 4:15 AM
Reply to this message Reply
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 [ « | 1  2 ]
Topic: One Awesome IDE -- CodeGuide Previous Topic   Next Topic Topic: Bozomind's Laws of Humor

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use