Development Frameworks

It seems that Java has as many development frameworks as it does developers. While that is an exaggeration, it is only a minor one. The .Net platform has a growing number of frameworks, although a large number are ports of existing Java frameworks. (It is interesting to look at the two communities and see why this exists (or if it isn't accurate, then why this is my perception), but that is a topic for a later post.)

Over time, I've been guilty of writing a framework or two. However, as time passes my opinions about frameworks have changed.

First, one basic tenant about productivity is that it is faster to use a good enough tool that your development team is familiar with than the perfect tool. Whether it is Java vs. .Net, Struts vs. JSF, etc. For every application you write, there is probably a different 'perfectly suited' framework.

Second, you should almost never write your own framework. This is an offshoot of the the previous tenant. You may come up with a framework perfectly suited to your problem domain. However, your developers will be unfamiliar with it, it will be untested in a production environment, and most likely, someone has already written something good enough.

I'm also becoming a bigger fan of agile (or at least iterative) development. This also helps drive the decision to use off the shelf or existing tools/frameworks. Otherwise, the deliverables from your first several phases will simply be framework components that you will need to assemble later. This prohibits you from getting valuable feedback from the business/requirements owners early on, which is a major value of iterative development.

There are times where the investment and cost may be justified. This may be true if you will be building and actively maintaining the system for a long period of time, and you require very fine grain control over how it works. If you are developing a system that will be delivered to someone else, it is even more important that you utilize well known tools and approaches to enable easy support and maintenance.

Finally, when electing whether or not to use a framework, you need to carefully weigh the cost of learning and working with it compared to the theoretical time savings gained. For smaller applications, it may often be worthwhile to use a more traditional brute force approach than to get elegant.