Having to double up in the role of project management and providing technical stewardship has allowed me to look at the topic of this post in very interesting light. The basic line of thought I’m trying to follow is with the myriad frameworks that have been spawned over the last few years, how much is the actual benefit that is drawn? How well do they solve or serve the business purpose for which they are employed? Are they all (or at least a good percentage of them) being leveraged to their maximum potential?
A Little history
Avoiding the technology platform pitfall, I’m talking about frameworks in general – be it the J2EE suite, .NET or any other technology group. The industry seems to be abuzz with a million different frameworks, each with their own claims of strengths and success and clusters of avid followers. To start off, a framework, in my opinion, is a generalized solution to recurring problems. Back in the days when web-based applications had just begun to unlock the door for businesses to evolve onto a whole new plane (the e in eCommerce), groups of the early explorers into this world began to face similar, but isolated problems. How do you ensure secure logins, ensure web-based application security, decouple the presentation layer from the business logic, avoid expensive database calls etc. And the solutions that ensued formed the foundation for frameworks – provide generic solutions that can be leveraged to solve recurring problems. And along with time, they started getting smarter – doing more than just solving generic problems, they started providing features that would drastically alter your applications (mostly for the better). Performance boosts, reduced life cycle times, decoupled layers, flexibility, reduction in resources required (including human resource) and more became the main reasons for the choice of frameworks. And today we have more than a few to choose from – Struts (and the hundreds that it has parented), Spring, Java Server Faces, Stripes and a whole multitude of .NET frameworks.
And the problem is…
So what could go wrong with a solution that is intended to make things easier? According to a report published by the Gartner group about 5 years ago, the unjustified use of EJB technology was costing US firms alone an estimated $2 billion a year over what they would have spent had they used more appropriate technology. And it would be rational to assume this figure has gone up over the last 5 years. So something seems amiss. From my observations, here are some contributing factors –
-
Complexity is equated with quality – There seems to be a general assumption that the more complicated of 2 options is the way to go. This is especially true in my area of work – Financial Services, where performing organizations are more conservative than other sectors, and less likely to take risks with a lightweight, not-so-popular framework over a bulky but widely-used option.
-
The inherent nature of frameworks – as I said earlier, frameworks are intended to act as generic solutions, but in doing so they become the victims of their own success by trying to solve more problems than possible to remain generic enough. Most frameworks these days come with components that have absolutely no value, or in fact are in the way, of firms using them. And internal rigidity within them limits picking and choosing what to use and what not to. If frameworks are akin to the chassis of a car, it’s similar to attempting to build both a convertible and a family mini-van using the same frame. Sure, there are choices in the amount of features you want to have, but take the more popular frameworks, and you’ll notice they have to remain generic enough to keep a broader target base, hence compromising on flexibility.
-
The Developers – Around the same time as frameworks started to take off, so did the industry in general. And that brought in hoards of career-switchers, who probably hadn’t had a lot of academic / professional background to have participated in the evolutionary journey from procedural spaghetti-style days, to the modern, distributed environment. Without having been through the pangs of dealing with some of the root causes that led to frameworks, I would imagine it would be difficult to look a little beyond what is offered by framework X into the rationale, or the lack of it. I’ve entered innumerable discussions with colleagues regarding a framework component or the other, and have invariably found it easier to get across to someone who has worked with a lot of, or even better without any, frameworks. It’s not what people know, but what they don’t that is the cause of concern.
If the axe is not sharp, it doesn’t matter how hard the wood is.
- Ancient Chinese proverb.
And that’s why I strongly believe in Aspect Oriented solutions – the right tool for the right job. Don’t get me wrong – I’ve employed various frameworks to great success and believe very strongly in their value. But evaluate carefully if you really need a framework for every solution. As Einstein said – “Everything should be as simple as possible. But no simpler.”