Frameworkitis and reuse

Erich Gamma:

Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it.

We prefer many small frameworks over one heavyweight framework.

(Read more at Erich Gamma on Flexibility and Reuse)

Well, I fully agree with this. Frameworkitis is a widely spread disease. It happens everywhere, to almost everybody. I assume it's somewhat difficult to understand you're suffering from it and to recover as well. Let me try to quickly point out some points I think could be considered as symptoms of frameworkitis.

Symptoms:

  • Versionitis. This symptom appears when you spend lots of time tracking out different versions of libraries for your projects. Sometimes you discover you cannot upgrade to a newer version of a framework you're using because the libraries the framework depends on make your stuff break. Take, for instance, XML parser incompatibilities.
  • Documentosis. This symptom appears when you realize you don't have the complete documentation of the framework you're using, and this is so old that the documentation cannot be found in the Internet. A variation of this symptom happens when a new release of the framework does not include a set of things that have changed; and you have to test your whole project again when upgrading versions.
  • Contracting difficulties. This symptom appears when somebody at your project just dissappears and you have to substitute her. Then you realize you have to hire somebody with extensive knowledge on tons of frameworks and libraries, and the cost for contracting a candidate just goes high and high.
  • Downloaditis. This symptom appears when you try to deliver client applications to end users and you realize you depend on a huge amount of things, so the end users have to download tons of stuff (If they ever do).

Frameworkitis is usually difficult to cure. For ongoing projects all you can probably do is to use something to manage complexity, such as maven (by the way, maven is moving to 2.0, so if you depend on 1.0 you may suffer versionitis or documentosis ;-) )

The best thing to deal with frameworkitis is, probably, to follow Joel Spolky's advice. This is, if the functionality you're seeking in frameworks is a core business one then just build it yourself, whatever it takes. As Joel suggests: "Find the dependencies -- and eliminate them".

Finally, if you have to use a framework, then I'd suggest building some sort of software abstraction layers (SAL) that depend on the framework, and make the rest of the project depend on these SALs. As you isolate dependencies in specific parts of your software you isolate the places where frameworkitis may appear. And then you're safer.

I'm writing this because a customer of ours is building a NetBeans module and wanted to reuse some parts of NetBeans, generating dependencies with other modules. Of course it may be a good idea (reuse is always a good idea), but you have to remember to balance reuse with dependencies, after all, nothing comes for free (but, of course, Solaris ;-) ).

I'm back from holidays (always short, you know ;-) ), so I'll post about the promised SwingWorker stuff (and about frameworkfobia, the disease I suffer), as soon as possible.

Keep on swinging,
Antonio

Comentarios:

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy