Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know that there should be a kind of standard for developing software but in the organization where I work for (30,000+ employees), we have a very strict framework for Java development.

In my opinion such a framework is prehistoric as we are therefor running at least 10 years behind (Standard is Java 1.5 but with support 'til java 1.2).

Further the framework slows down performance, user satisfaction drops and I'm writing more boilerplate code than is good for my health :-).

Any suggestions on the advantages of such a framework? What are good practices for such a framework for not running behind the facts?

share|improve this question
    
Is this "framework" replacing the JRE, or is it more domain oriented tools and objects? –  AJ Johnson Dec 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... –  Dave Dec 10 '10 at 13:49

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer
2  
"Frameworks need to evolve over time just as all software does." +1. Stagnating enterprise frameworks are the grandfathers of technical debt. –  AJ Johnson Dec 10 '10 at 14:34

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.

share|improve this answer

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.

Is very apt :)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.