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 all 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.
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 all 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.
Excelent!….I’had a similar opinion over those frameworks but now i’m a spring evangelist too 🙂
I’m not exactly an evangelist. On each occasion I weigh different technologies. I did a presentation on CDI (http://techblog.bozho.net/?p=286), so “evangelism” is not the best word here, but these frameworks are really making things better.
Theres two sides to the coin…
Architect’s Side:
There’s a phrase that applies here, “When (all) you have is a hammer, everything starts looking like a nail.” At my shop, we use spring extensively. Some of my developers began writing interfaces for the most ridiculous of things… We had a maven project that had 6 classes total, and all 6 had matching interfaces and three spring context files. When I questioned the design the developer replied, “well that’s good programming habits.” He was correct, somewhat. Theres a couple of problems… One, I’m under the philosophy that the system should only be extensible if and only if you know you’ll be extending it: “Cross the bridge when you get there.” The problem here is that he could have done this without using Spring at all! The code would have been a very clean implementation without it…
On the other hand, I do agree with out on your “write our own framework” point. Unless your business’s income is based on writing frameworks, don’t do it. You’re burning valuable project time to fulfill the devoid egotistical fantasy that you’re contributing something relavent to the world of computing. Guess what, it’s 2011 and most every-day problems on Turing machines has been solved already. Don’t burn your project hours re-inventing the wheel. Stay focused on the end goal, which is delivering your product. Concentrate on building re-usable business logic, not reusable technology.
Sometimes though, the goal of other person is to build a framework, not use a framework. The best way to deal with these types of situations is to get ahead on your project work to demonstrate respect for seniority. Once you have demonstrated this, showcase your clean, alternate solution that’ve you created in your personal time. Remember to sell these things in “business language,” so speak in terms of hours, dollars, and maintenance time. A thorough analysis that speaks in such business terms wil speak louder than the code itself.
@Jonathan Fisher exactly. The first example is a case when frameworks are not required. There are such cases. You are also right about overdesign – as I mentioned, it’s one of the worst things that can happen. Writing 10 classes for a CRUD (a bit extreme example).
But the average project out there benefits greatly. It’s just that not many people want to admit their project is an average one.
I once had an interview with a small company. I am glad I didn’t progress further with them due to some of the red flags they set off during the interview. The one red flag I remember the most was a comment made by the manager who stated that they had looked at Spring and the *lead architect* couldn’t get his head around it, that the learning curve was too steep, so he invented his own framework for the same purpose.
I am not a genius, it took me a little longer than it should to grok Java when coming from C++, so when I say that I picked up Spring fairly quickly, then that is not saying much. It does put into perspective where their lead architect must have been though. How much time was wasted learning how to solve a problem that someone else had already solved??
Some frameworks are indeed too complex, too heavyweight and have other problems – but there are usually alternatives for the same problem domain that address those concerns. When I see someone reinventing the wheel where a well known, well used and well tested framework would have been a much better choice, then I tend to want to avoid that project.
I would start with the best sentence in our field – “You need to find the right tool for the given job”, and not searching for nails being a hammer-ist (as mentioned above).
I’m definitely a framework supporter – because of them being standards, being well-documented and because of the existence of the large communities that could help with that. Not to forget IDE support and other goodies involved. However, I would rather work with 2-3-4 different platforms and even languages depending on my type of projects – whenever I need security, scalable and robust platform with extensibility in mind, I would use some JEE stuff such as JSF with Spring or EJB or something. If I need a lightweight software for rapid development, I’d chose either some Wicket-based product or PHP/Python.
You already mentioned that bootstrapping takes a week for a “Hello, World” project with most frameworks – one script dev could design a simple working social network or collaboration platform for that week. 🙂
I totally agree with the comments that “if all you have is a hammer then everything looks like a nail” and “the right tool for the job”.
I suspect that developers often use Hibernate as a substitute for knowing how to use an RDBMS and SQL. I may be wrong in most cases, but the many cases where I may be right scare me. I don’t think Spring makes all the best implementations for everything or is an appropriate framework for most projects either, YAGNI.
I do understand the Spring and Hibernate shop mentality better now, though. The quick learning curve on existing projects and quick rampup on new projects for developers experienced in these frameworks means there is very little lost with developer turnover at the company. It’s a widget factory with developers out and developers in.
This is also preferable to the reinvent the wheel shop, which is almost always done badly and even mediocre frameworks and tools would have made the app much higher quality.
I would still rather pick my own favorite tools, frameworks, implementations appropriate for the particular application, though. There are no guarantees, but I think this keeps the application as high quality and simple and elegant as possible. If the application is designed well and the original framework choices want to be swapped out (due to new requirements or because the inheriting developer(s) like another framework better), this should still be little more trouble than having picked an all encompassing framework like Spring or Hibernate in the first place, IMHO.
@Mario, I was also about to use the phrase “the right tool for the job”, but decided it’s cliched and subjective. Because people can claim core java is the right tool, and we’re back to the original non-debate.
As for the hammer, the good thing is that you have many hammers of different size and also screwdrivers and pliers. I used spring and hibernate just as examples, because they are often the most discussed ‘evil frameworks’.
And about the scripting guy – I agree he can get something working pretty quickly, but, you know better than me, if that thing grows and later needs to be handled by a bigger team, it can be painful.
@Bozho, I don’t want to start flames, but think about the top projects in the world (in visitors and registered users etc manner, such as Facebook, Wikipedia…) and consider how many of them are implemented via scripting languages. People who do not do scripting underestimate badly those languages. It was insulting to me to turn back on Java few years ago, but now I can clearly separate different subsets of clients, projects and the appropriate technological stack for a given case.
I have another question in my head to be considered. Languages such as Java and PHP have tens or hundreds of web frameworks. On the other hand, Ruby has its Rails, the .NET platform – ASP.NET. Python is somewhere in the middle (Django is probably the top favourite, although they have Pyjamas which is GWT for Python and some other projects). I just wonder whether having one powerful but restrictive at some point framework is better than inventing tens of others.
@Mario for the letter question – it seems either way works.
As for scripting – I guess “either way works” fits as well. My personal experience and opinion is in favour of non-scripting languages, and I claim you can have the same speed in Java as well, with one condition – you have to be very experienced 😉
The reason I am against frameworks like these is that they lead to really bad habbits. Instead of building clean database schemas and class APIs you have to contort everything to fit the framework.
When you find yourself making every method virtual you’ve failed.
When you find yourself putting setters on every collection property you’ve failed.
When you cannot unit test a class without bringing in your DI framework you’ve failed.
When your class hierarchy looks like your table schema instead of domain objects you’ve failed.
You are free to have final methods, you don’t have to put setters, you can unit-test without the DI framework (in fact, I usually do so. And that’s a plus of DI – it forces your classes to be more testable). And I never start with a DB schema. I always start with classes. So your remarks are not quite fair, I think.
I don’t mind frameworks, but I don’t like open source. Doing things different than the next guy is our competitive advantage. All contractors and consultants, feel free to rage that this statement. I know that is in direct conflict with your profession. Having to learn something new on a client-to-client basis is bad for outsourcers.
Thanks for this article.. I think I’ve made all those arguments and this article just shook me to my core and woke me up…, thanks for saying it straight to my face. I was so complacent with the current homegrown framework to which I also contributed in a great way and so was dear to heart and was hard to let go.. and I’m the kind of guy who can’t accept anything until I understand what’s happening under the hood – but recently has become so lazy to tinker with framework source code. Anyway, out of necessity I’ve started (very late) to dig through the source code of Spring and Hibernate and I feel comfortable and feel confident now.. IT projects where someone has to code business rules kill Comp. Sc. and so it was kind of working opposite for me I guess.. I think our first defense & instinct is to despise anything we don’t know or understand. Once again thank you for this article and probably saving my career.
I don’t agree with your assessment. I’ve been using the Spring Framework for years in several projects and still find it a clunky mess with poor documentation.
Hence, all the employees of this place are mandatorily recruited from the state itself.
A no deposit casino is a great option for you to look into when checking out online gaming options.
Those men, in addition to carrying weapons appeared to have containers of some kind with them when they entered
the Monterrey Casino.