written by owen on 2011-Dec-15.

Frameworks are what they are, they will save you a lot of time when deadlines are tight and give you tons of free code and documentation to read. But as in everything there are disadvantages and advantages which is why you are reading this article today. This article seeks to outline some of the pitfalls of software frameworks in general. It touches a little on programming paradigms which are frameworks but they are all children of the same mother. This article is aimed at the experienced programmer, if you are a noob you will not know half of the things I talk about here so this article will be of no use to you.
From now onward when I refer to the word “framework” I am usually referring to frameworks that OTHER people write, not your own custom framework. I can’t see your framework but in most cases you know how it works while most other frameworks are magic. Also I am refering to frameworks built on top of another language ( because if you have no choice in how you write code then you are pretty much stuck with no way out ).

Frameworks are hammers

Some people seem to think that frameworks are the be-all end-all of programming. Frameworks are tools like a class, array, pointer, for-loop, hammer or a saw. You CANNOT use a hammer to make a hammer. It is not possible, you will always be limited to what the framework is designed to do - which in the case of the "HammerFramework" is to drive nails. To a "framework nut" EVERYTHING looks like a nail. They will spend years planning and charting an API for a problem then realize that it is pointless in a single day (then refactor the entire thing). Frameworks solve a specific set of problems. It would be good if you just drove nails all day but sooner or later you will meet up on a edge case. This limitation will often only manifest itself years after the project has grown old and rusty and then you try to make some major change to how it works (I'm looking at you Apache STRUTS). At which point you realise that there is a invisible wall around you, a new version/fad probably gets released and everybody quickly re-factors all their old code to match this new found version - totally forgetting the last 2 years of pain and repeating the mistake again. This happens time and time again.

Useless code

Few people realise that if you write all your code in a framework you will end up with code THAT IS TOTALLY USELESS. In a framework, code is a extension of the framework, everything written is dependant on some convention that somebody dreamt up while sitting on the toilet. Copy ten lines out and paste it into another language or app and try to run it - it won’t work or even be fixable. And what makes it worst is that each framework has it own set of little classes/functions that are unique to it. A model can be anything in any number of frameworks, there are often no consistent way of working with them.
Most programs written in frameworks are often TOTALLY REFACTORED when they are updated or moved around. I have functions that I had written 5 years ago that I am still using today - what about my framework code? Useless! Most of it is filed away or deprecated. This uselessness occurs because the code does not carry any of its own MEANING. All it was doing was pushing levers around, shifting pieces from one place to the next. The few places you do have actual business logic are often dwarfed by the share amount of infrastructure needed to hold it up. Re-factoring is something often used to to hide this side effect. This happens every time a new thing comes out or a new version! There are even tools that do it for you! But you will still need to go and look at every single line because nothing is perfect. This only happens with code that is written in a kind of framework, you will NEVER see people refactoring a for-loop, because a for-loop is a language construct it serves a SPECIFIC PURPOSE and carries MEANING. Frameworks seek to abstract as much meaning as possible away from the code. Refractoring and schema updates are a problem - NOT a solution.

Discourages sharing

During my research I read an article that pointed out something that I did not even realise; Frameworks discourage sharing! Say for instance I write a "contact us" page in an MVC framework, you would think that it would be possible to share it with another programmer using another MVC platform, right? No sir, because code that is written in a MVC framework is so fragmented that parts of it makes no sense outside of the framework context. Further more you end up with 3 or 4 files, then you realise that you will have to send the helper code as well, eventually you have to send the models, then the WHOLE PROJECT just to demonstrate how one part of the code works! What people don’t realise is that your code and your framework are married at the hip. You are not using the framework - the framework is using you to propagate itself.

Force you to do unnecessary work

Frameworks are self supporting, and they make programmers do unnecessary work. Instead of solving common programming problems, most frameworks seem more interested in giving extra things to do to distract you from actual problems. If you have a SQL injection problem they give you a NEW OOP Abstraction layer which replaces all your SQL. If you have a PHP in HTML problem they give you a whole NEW template language to learn that is a little like PHP but alot like HTML but is neither. If you have session state problem they give you a class structure that you have to inherit and extra functions you have to call to get your program to work.

It would not be so bad if you could pick and choose between the features but they are often tightly woven into the framework mesh. By the time to get up to speed, you will have totally forgotten you initial problem. Its all a distraction, if you want to set up rules use a programming language that has those rules built in - not a framework.
I have used many frameworks and I often wonder why am I putting 2 files into this folder and 3 files into another folder? It is not because of some useful reason - ITS BECAUSE THE FRAMEWORK WANTS ME TO DO IT. obviously it would be too much work for the framework designer to figure out what is what, based on the code you write, which is why you are forced you into some kind of “convention”. Why can’t I do a CVM in my MVC? or a VVC in my VCM? It is because each framework is hard coding a set of rules which make it work. These rules/conventions in a framework are just another wall between you and the solution to the problem. Look out for these convention/rule hacks and you will be the wiser. Once you go outside the bounds, you are on your own. Hack the framework, extend it - its all the same thing. If you problem is unique or complicated even in the slightest be prepared to spend 5 years writing handlers and scaffolding to get the expected results.

Additional Overhead

Remember I mentioned earlier that the framework and you code are joined at the hip? Well when you program is finally done (if ever), look at the size of your program + framework. If your program is 500 lines and the framework is 1 million, then your program is 1 million + 500 lines of code. That framework is now apart of your program and all the requirements that come with it. Just accept it. Any changes to your program will end up being framework changes (especially since you code is meaningless). If the framework needs to run on 64 gigs of RAM on a cold room server then your program needs it too.
Suppose every page in your program had to have 5 files? Lets say you had 50 pages, that is 50 * 5 = 250 separate points of contact - not counting models, helpers etc. Worst case say you have 10 pages which share views and models with a random number of other pages. Anybody adding or removing anything thing from your program would either have to be YOU or spend a great deal of time looking through all your code, AND the framework you used to understand what effect the change will have. Oh, well, yeah you could run the unit tests, lol, or write some new ones. This is something you just have to accept, DO NOT FIGHT IT. Major changes to code written in a framework - no matter how well designed - often results in a total rewrite. See because you use a framework does not mean that your code is well written or easy to maintain. A bad program is bad in anything it is written in.

Limits Innovation

Lets face it, frameworks are training wheels - only people who ride small bicycles use them. Even the large scale riders are often using highly customized versions (at which point they are like training rockets), or are stuck on legacy versions because they are too afraid to spend millions of dollars to upgrade their entire system to the lastest version (or really don’t care to).         If you have to spend all your time searching through a plugin directory for solutions to your problem then you are clearly a small bicycle rider. What makes it worst is that in 5 years you will still be riding the same bicycle.

The majority of the other framework users spend a year learning their framework before another version comes along to give them features that they couldn’t possibly implement themselves - why you ask? because it is the nature of a framework, its designed from end to end, you have to play in the little sandbox - again DO NOT FIGHT IT. Companies who realise that thier framework is holding them back often spend years hacking at the framework or hire some core devs to modify it to fit edge cases but by then they would have gone so far off the reserve that they either have to spend big to maintain it or make a quick decisive blow to the head. The rest of use poor mortals just have to wait and hope that the framework gods smile on us, maintain backwards compatibility and our long awaited feature request gets put in the next major release.

Why use a framework?

Frameworks arose for two reasons; because programmers like to share, realised that some people need training wheels and just cannot learn how to keep themselves on the right side of the road without hitting the guard rails. Secondly, businesses and managers needed a way to industrialize the process of software engineering. If you have large teams of programmers with mixed proficiencies, 50% of which are below average, the best way to get reasonably good code is to have them all working in a framework. Give them a framework! The bigger the framework the better! Frameworks also make it easy to swap people out if they get too complacent, since it is easy to find somebody else who can learn the same generic framework and continue the work. So its a win-win situation. Based on how you look at it.

Conclusion

Find the right tool for the framework for the job, the smaller the better, because in the end everything sucks. Frameworks save time and money BUT will not make you write better code, in fact it may even make your code worst. A framework will not make your code any more readable, reliable or maintainable (its basically swapping one set of bad documentation, for another large set of bad documentation ). It is important to understand your choice of framework - how it works and avoid trying to shoe-horn everything into a single sandbox - that will only limit you in the long run. Look out for Framework Caveats. Document your code, KISS, try to predict what future enhancement you may need and do proper testing early in development. Do not be afraid to ask questions. Do not be a sheep. Test out edge cases early in development - even if you have no present need to do so. Always read change-logs when they are released and keep abreast of new developments in your framework. You never know when a new framework version will come out. Probably next year.

My next article will be on the future of frameworks and how they should actually work. Look out for that.

permanent link. Find similar posts in Articles.