Every few months we see a new framework springing up somewhere. Now we have too many choices. In fact it is little too much. Unfortunately, choice is something you don’t have in a typical enterprise. In an enterprise, software developer is coaxed to make use of many frameworks from which he would rather run a mile away. Not a day will go by without him criticizing them. Is something wrong with today’s developers? Why do they always keep criticizing about something which their managements rave about?
Before I continue I should clearly define, what I mean by (software) framework. I consider a framework to be a package (a closed box) of code that helps a developer to instruct the computer electronics to solve some problem. Now this problem could be of many types. You already know that instructing a processor in their native language (machine language) is no simple task. In other word this is a problem. To solve this we have the OS. Yes, OS is a framework too! Think about this. OS provides us with some basic APIs to read file, read from network, allocate memory , display output, taking input, and so many things. Your program doesn’t have to code them. OS provides APIs for them. So, OS too is a framework, which solves some common problems. To interact with Microsoft Windows’ API a VC++ programmer will typically use MS Foundation Class (MFC) library. This is needed since interacting with raw Win32 API in itself is a problem. It is very difficult to use. To ease that VC++ provides MFC framework. So, a typical framework also solves the problems in other frameworks.
No software in this world is perfect. If they were then there would have been no software industry, as service accounts for 70% revenue. They all have problems. This means there is always scope for a framework which solves that. However, the framework itself is a software, that means we need more frameworks to solve that! This has given birth to today’s infinite stack of frameworks. Stack of frameworks is no doubt needed but an infinite stack is always ridiculous. Infinite stack is a condition when developers try to fix problems from the top of the stack instead of going down and fixing the source of it. Unaddressable problems in a framework usually arise from design issues and lack of foresight. Perceived problems in a framework arise from framework user’s lack of understanding of the scope of it. In either case the developer using the stack should remove the problem framework, but usually end up adding a new framework to it. This is because – 1) It is cool to create a framework. 2) It is much easier to code a framework than make management understand why you want to change the stack. Once plagued with this condition the stack will inevitably grow like cancer until the hardware begs for mercy. At which point it will be declared that the stack is too advanced for current hardware.
Broadly classified, frameworks are of two types – thin and thick frameworks. Thin frameworks try to ease out some kinks in some other frameworks. Thick frameworks are the one which promise to do every god damn task you throw at them. In future if technology permits then maybe we will see a thick framework which will not only write the codes for you but also clean your kitchen floors. :p If you are a developer then you must have come across some frameworks like these.
It is interesting how sales people have changed the jargon to market frameworks. They do not use the word framework. They say it is a ‘technology’. Typically thick frameworks are marketed like this. Sales people will typically list out mind numbing number of features and at the end of the presentation the only thing you will remember is that this ‘technology’ is very powerful and hence awesome.
Endless frameworks stacks are no doubt ridiculous, but thick frameworks are evil. You depend on them and when things don’t work out the way you want then you will have run after their creators for help. Remember they are closed box. In industry parlance, they are black box. So, you know hardly anything about how it works. Do you want to take the risk of using something which does 90% of the job without you knowing anything about it? Thick frameworks, even when open source, are still dangerous. It is simply because they are so hard to code and could possibly have loads of bugs. This brings us to an interesting point. The code that we build on top of a framework in itself is a package of frameworks, in fact we can call that a framework too. So, does this mean the bigger the code is the more unreliable it is? Well yes, of course; but we try to minimize that by dividing the code into distinct (almost) independent parts. So, this means when evaluating a thick framework we must always try to identify the independent parts in it. If any such part is too big and complicated to understand then you should not go ahead with it.
A user of a framework must understand how the framework works. A normal user of OS need not know this, but as a developer you must know. This is because a normal user will always stay within the bounds of the foreseen scope, while the developer needs to push the boundary of it. By the time a developer understands that the current stack may not fully meet his requirements, it is already too late to change it. The only way around in this case is hack it! To hack it you need to know it inside out. For example, it is best to avoid a web framework which is so thick that you don’t even have the slightest idea of how it routes the HTTP packets inside it.
People now a days seem to miss the point of creating a framework and ‘technology’ stacks is solving problems, not multiplying them. Never make a framework which has more problems than the number of problems it solves.