Is this "framework" replacing the JRE, or is it more domain oriented tools and objects?
–
AJ JohnsonDec 10 '10 at 13:41

@AJ It is more then just the JRE, there are mainframe and Oracle DB mappings (based on Struts), there are own tags for writing jsp's, ... Like for instance the oracle DB mapping, I know 10 years ago there was no Hibernate or something like that. But I know now that hibernate works 50 times faster then our mapping...
–
DaveDec 10 '10 at 13:49

3 Answers
3

What frameworks are meant to do is to simplify, or organize software development in some way that has benefit. Unfortunately, unless the framework evolves with new advances in the language, those advantages it affords are probably overtaken by events. For example, 10 years ago there were a few Java frameworks, but the one that has the widest acceptance is currently Spring. Anecdotedly, I remember hearing about Spring and thinking to myself it'll never get anywhere. I was wrong.

It's important to understand what problem(s) the framework was intended to address. If your organization has to support 10 year old installs of Java for whatever reason, and the framework ensures that new code will run on old VMs--that's an important advantage to the company. However, if there are no advantages whatsoever to the old (and possibly aging) framework, then you will probably need to take some statistics.

Nothing speaks to managers more than numbers. When you show them how much of your work is due to feeding the framework vs. how much time it would take to do it another way. Perhaps it would be much less political if you were to address a specific portion of the framework that if changed would buy you another x hours of productivity during the day.

Frameworks need to evolve over time just as all software does. As new features come out in a language, the framework needs to be adapted to take advantage of them. The Spring of today is hardly the Spring when it was originally introduced.

I've seen both, organizations with specific frameworks and others without.

Having a framework and strictly sticking to it means that every programmer can, at least in theory, work on any part of any project. This is a big advantage for a large organisation. There are, obviously, at least two downsides: a) at some point in time, it becomes out-dated, but you have to stick to it for all those millions of LOC that use it; b) you use it for every project, whether or not it is a good fit; so it's a golden hammer (see antipatterns)

On the other hand, organisations without a framework tend to use new tools for every project, thus having a fragmented codebase that becomes hard to maintain. "Oh, the 2003 project needs an update, where is the VB6 programmer? Sh*t, he left in 2007!"

It's no surprise that some organisations manage to implement the worst of both worlds: an outdated in-house framework for some projects, several other tools for the other projects.

Quite often organisational frameworks pop up because external frameworks "weren't invented here" and equally as often "There's nothing that current meets our needs" (which was quite common in the early days of J2EE).

The wise organisation has plans to move parts of their own internal frameworks onto industry standards (e.g. JPA)

And/Or

The wise organisation has plans to improved their own internal frameworks to increase developer productivity yet maintain what ever special support that is required

And/Or

A truly brave/enlightened organisation might open source parts or all of their framework in order to keep it up to date, relevant etc.

Most organisations don't do this and ammoQ's comment:

It's no surprise that some
organisations manage to implement the
worst of both worlds: an outdated
in-house framework for some projects,
several other tools for the other
projects.