Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

Those evil frameworks and their complexity

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.

Reference: Those evil frameworks and their complexity from our JCG partner Bozho at the Bozho’s tech blog.

Related Articles :

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


× nine = 54



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books