Sunday, February 05, 2006

Frameworks

This is one of my favorite topics of late, especially in the web development and Java universe. If you are working with Java or any of the object-oriented dynamic scripting languages (Python, PHP, Ruby), then you are most likely working with a set of frameworks. If you are not using frameworks then I am not sure if you or I am in a better situation today.

I just read a blog posting "Why I Hate Frameworks" which pretty much sums of the state of frameworks today in the Java universe. What is ironic about this posting is that most of my experience with frameworks fits the hammer metaphor described in the article. I dub this 'framework hell' which is analogous to the the 'DLL hell' that exists in the Windows universe today.

If you are not currently working with a language/framework set or are just getting involved, then you will encounter the framework complexity and integration fiasco sooner or later. When you do, then all this will make sense to you. The general purpose framework days are over in modern software development. Frameworks are the trend for solving just about everything today and you can find at least a dozen framework to solve every single little part of your application in a highly granular fashion. Note, not all frameworks work or play well together. Most of them are designed independent of one another by teams of programmers that may or may not even be aware of each others' framework efforts or existence. This is the root of the problem.

The complexity and state of frameworks today is mind boggling. At least to me it is. Every few months, there is signficant progress made in the frameworks that I use or the frameworks I am researching to justify a possible change in technical direction. I don't mean just to following the technical winds of the day. Many of the these advances are significant enough to contemplate a disruption in forward technical progress.

Obsolescence of a framework is a real risk. In the last four years in the Java community I have seen some frameworks and APIs become obsolete as a newer better, faster, lighter technique picks up momentum and takes over. (i.e. Spring, AJAX). This continues today in 2006 as convergence of AJAX techniques takes shape. Recall that AJAX was a disruptive technique in 2005.

Maybe things will get better later this year or next, however for the foreseeable future, I think the state and complexity of frameworks will continue on course. What course that is up to the forward progress of the researchers, programmers, practitioners and companies that are driving this forward progress. Don't get me wrong, frameworks do work well when appropriately understood, applied, tested and proven. It is just the fact that your framework usage may become obsolete sooner than you think and you are left using deprecated technology.

I guess this is the cost of rapid forward progress. I am not complaining about it, just stating that rapid innovation in and of itself can be like one huge experiment that can shift and change directions without any warning. One month, you are using the best of breed and the following month you are re-engineering, refactoring, or simply researching better techniques which may cause you to consider making changes soon. If you follow framework intergration best practices (I am not sure which ones there are so many and everyone has their own viewpoints), loosely couple, design for change, use agile techniques, and keep an open mind, you will probably be successful in your framework endeavors. Good luck.

1 comment:

p\/ said...

Slashdot just posted an article discussing framework decisions and which one to use. How Do You Decide Which Framework to Use? This has a lot of good links comparing JSF vs. Struts, JSF vs. ASP.Net). Lots of good info.