Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 91 posts at DZone. You can read more from them at their website. View Full User Profile

Those evil frameworks and their complexity

09.05.2011
| 5407 views |
  • submit to reddit

Frameworks like Hibernate and Spring are industry-standards. JSF, EJB and the likes are also standards and used in many applications. But there are always people that are against these frameworks. This is a language-agnostic topic, and although I’ll be giving Java examples, this applies to every language.

The usual arguments against using frameworks are:

  • it is very complex, we don’t need it
  • we can make our own framework that will be better for us
  • we doubt their quality and don’t think they can do the job
  • we don’t want to learn yet another framework, core java should be enough
  • we’ve never heard of those…what’s so good about them?

The bad thing is you can’t argue with these people. And if they happen to be leads or architect – here’s another screwed project. No, don’t get me wrong – there are pretty valid cases not to use these frameworks. But they are not the common project out there. Let me discuss each of the above arguments

“it is very complex, we don’t need it” – complexity is indeed an issue with frameworks. Botstrapping them may take a week. But the complexity is only there in the beginning, until the team gets fluent with the given framework. Then complexity remains on a fixed level. I can tell that from experience – I came to my current company and they had a big project using spring and hibernate. And I could fix anything in that project after a week or so. Because a spring project cannot grow complex. It just grows bigger, with a fixed level of complexity. It’s not about algorithmic complexity, it’s about structure and configuration.

And that’s the problem with “we can make our own framework that will be better for us”. With that complexity is likely to grow to infinity. Not that it always does, but homegrowing a framework and reinventing the wheel has often lead to unmaintainable projects.

And not to mention the fact that your team is about 5-6 people, who have to create business value, and don’t have the time to write frameworks. And that compared with the thousands of hours spent on open-source frameworks, and the millions of hours spent programming with those frameworks and finding all kinds of issues and problems possible, makes the “we doubt their quality and don’t think they can do the job” argument look unjustified. The quality of popular frameworks is much higher than the average team can achieve in a project lifetime.

It is true, however, that some people lean in the other direction – overdesign. And overdesign is, in my opinion, the worse thing that can happen to a project. And “we don’t want to learn yet another framework, core java should be enough” looks like a point in the proper direction. But it is another thing in disguise – incompetence or inability/lack of desire to learn. I’ve heard so many rants (including questions on stackoverflow) about spring being over-complex and bloated, or that hibernate takes control from you and creates many problems. I won’t go to explain in what way exactly these claims are wrong, but they exist because people do not understand those frameworks well. And the seemingly easier path is to just drop them.

On the other hand people tend to throw in frameworks they don’t understand just because they are popular. And then other people blame the frameworks. You can spot the common theme – it’s not the frameworks that cause the problems, it’s the people that do not understand them.

Well, this doesn’t mean all frameworks are good. EJB 2 wasn’t. Struts 1 wasn’t. But you can only afford to blame the framework if you know what its real problems are and how to fix them. Gavin King and Rod Johnson knew. The others used EJB 2 and probably had made a better choice than homegrowing a framework that would be even worse. Yeah, you are the super-architect and yours was better, I know. If you are, feel free to give me a link to your spring/hibernate/etc.-killer.

And then the “anti-frameworkist” can exclaim “why on earth should I learn every new framework out there”. First – you get paid that much because you are supposed to learn new things every day. Second – popular frameworks popularize best practices and concepts. They make you learn those best approaches to typical situations. And there’s another advantage – being a spring expert you can easily learn any other dependency injection framework. Being a hibernate expert you can easily learn any ORM (or in fact – any tool for mapping objects to non-OO data stores (including NoSQL)). In other words – configurations and methods are documented and can be easily checked. Concepts are what is important with every framework.

So it call comes down the the skills and understanding of people choosing whether or not to use a given framework, and whether they can properly evaluate the pros and cons, and the suitability for the current project. Frameworks are there to ease development, not to make it more complex. They introduce initial complexity, but the good ones fix the complexity to a relatively-low level afterwards.

 

From http://techblog.bozho.net/?p=358

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jean Said replied on Tue, 2011/09/06 - 7:17am

The main issue with behemoth frameworks is not what is in it. It what's not in.

How much does it cost when you have to workaround a feature of the framework when it does not perform like you wish? That's the main issue with heavyweight frameworks. Of course a framework have an added value and of course it will cost you to develop something similar, and some high quality stuff. But the added value come itself with a cost, even much more than the learning curve.

I don't mean to say using frameworks is bad for you, what I say is that you need to be aware that there is no silver bullet and what's not in the framework is going to be expensive in proportion with the framework complexity, and probably more expensive than you can evaluate in the first place.

You can't foresee what's not it, but keep it in mind that pain may come from the lack of flexibility that frameworks create.

Mark Unknown replied on Tue, 2011/09/06 - 8:31am in response to: Jean Said

First it starts out with "this framework doesn't contain what i need". Then it ends up being "This framework contains too much". Both were said about Hibernate and Spring. The thing is, will you be worse without them and do they allow you enough flexibility deal with the niche issues? My experience says yes.

Ronald Miura replied on Tue, 2011/09/06 - 9:20am

The others used EJB 2 and probably had made a better choice than homegrowing a framework that would be even worse. Yeah, you are the super-architect and yours was better, I know. If you are, feel free to give me a link to your spring/hibernate/etc.-killer.

Er, no. Nothing can be worse than EJB x < 3. The question is not that they (who used old EJBs) would not be capable of creating a Hibernate or Spring killer (arguably the state-of-art in their fields), but that they could've used plain JDBC and POJOs, instead of BMP Entity Beans and locally-called-remote-Stateful-Session-Beans. With their own infrastrutrute, yes, but probably easier to understand than a framework on top of EJB (which they probably have done anyway).

Mike Dzone replied on Tue, 2011/09/06 - 10:01am

Any Spring or Hibernate project I am on, I spend 3 out of 5 days troubleshooting problems these fameworks make.  Whether it's configuration problems getting things working or production problem with things breaking.  I thought frameworks were meant to free us from these types of things and allow us concentrate on our business code.  HA!  That's a real laugh.

Suck NR replied on Tue, 2011/09/06 - 10:48am

I think there's a big difference between frameworks that support declarative configurations, e.g. Spring, versus those that rely on convention-over-configuration and other such voodoo. When the latter goes wrong it is often very hard to resolve the problem or work round it.

Jose Maria Arranz replied on Tue, 2011/09/06 - 12:11pm

You are missing the most important thing regarding this subject: abstraction level.

You are EVER using some kind of framework, some level, be Java based, be C based, be any other language. Almost no one writes machine code these days.

Abstraction is fine because it usually improves your productivity because you are adding already-cooked stuff. 

But it has a price.

The more abstraction the more inflexibility, less control and more risk of not successfully doing the thing you specifically need.

The key of this topic is how much abstraction are you going to afford and in the same time get control of the technology and get aligned with your needs, your objectives, the desired performance etc. If your tool is of very high level or the kind of abstraction you don't need, you end figthing AGAINST the framework trying to fit it into a concrete problem it wasn't designed, adding tons of hacks and spending hours and hours to solve a problem trivial in a lower level, ruining your productivity and productivity is the key of using a higher level tool.

As you can see the problem is not black and white.

 

Liam Knox replied on Tue, 2011/09/06 - 5:18pm in response to: Mike Dzone

I would really question whether you have actually learnt the framework you are using in this case. If you believe you can write your own messaging, threading, management and configuration then be my guest though if you can't use Spring in sincerely doubt your ability to deliver better

As for the authors comment on quality it seems very subjective though I would argue that no one posting anything here could deliver the quality, well thought through API's as delivered by Juergen, Rod etc.

The main problem in the overall developer space is that many believe they can deliver frameworks and they have ability to throw their own crap solution, like a grenade, into the world. The many worthless languages, API's and frameworks that get some air time detract from the best of breed which actually benefit the world.

Lance Semmens replied on Wed, 2011/09/07 - 4:44am

Everyone praises hibernate but I'm not so sure. Since the database is usually the slowest component in your system, I think wrapping such a complex abstraction around it is dangerous. If you turn on SQL logging for an application using hibernate, you will see what I am talking about. In most cases, there are many unneccesary SQL statements being executed that would not occur if the team was using plain JDBC or a simpler abstraction (such as myBatis). Sure you can spend hours / days tweaking your hibernate config to get it right but in my experience this does not happen enough and consequently the app is slower than it should be.

Liam Knox replied on Wed, 2011/09/07 - 5:46am in response to: Lance Semmens

I agree Hibernate is praised too highly but it is as much to do with ORM's in general. Relational DBs and OO code are just chalk and cheese. Thinking that you can mesh the two with a few annotations will not cover many systems or use cases

But if you did look at other abstractions such as Spring JDBC, myBaitis etc. you can see where a framework cuts down the boilerplate but allows you access to tune, specialize etc. where needs. And again something like transaction management I would much prefer a framework to manage this.

Mark Unknown replied on Wed, 2011/09/07 - 9:31am in response to: Lance Semmens

The question is ... is it fast enough?

Software development is full of trade offs. Saying ORMS are always wrong is just as bad as saying ORMS are always right. It takes ability and sense and experience to know when. You can spend your time with niche issues or you can spend your time writing a bunch of code - again and again -or "building your own framework". I don't use Spring and Hibernate because it is cool to do so or to pad my resume. I use them because, as a good developer, I saw the need for IoC/DI/AOP/ORM before I found Spring and Hibernate (maybe even before they existed). I and others started to write our own solutions. Any good developer WILL create abstractions (aka "Why am i writing this again?"). As someone said elsewhere, other people can and did do a better job than me (and most of us).

FYI - with Hibernate, you can write SQL if you NEED too. You are not just stuck with tweaking configs.

Liam Knox replied on Thu, 2011/09/08 - 2:22pm in response to: Jose Maria Arranz

Look at Spring. Rod went through enough iterations(4?) to realize the best fact of a framework is don't alienate people.

Liam Knox replied on Thu, 2011/09/08 - 2:28pm in response to: Mark Unknown

what is fast?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.