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 :
