Upsides:
Surprisingly I feel divided about using software frameworks. On the one hand if you use a software framework it is a sign of professionalism. If a person is applying for a job or if a 3rd party is doing IT work for you, it communicates a lot of good things about them if they advocate the use of and have experience in using software frameworks. It says that they are smart enough to leverage the work of others, it says that they understand and are addressing some important challenges that exist in the domain of work that they are engaged in, it says that they will create maintainable code that others will be able to work on. Based on these observations, you'd think it would be a shoe in that I would always use frameworks on my own projects and favor working with individuals that use them, but in actuality it doesn't always go that way.
Downsides:
This summer I've had some recruiting companies contact me about job openings. They were desperate. In one case I had several recruiters contact me about the exact same job at a particular company. The issue at hand was that they badly needed someone who knew not just a particular programming language, but a list of important libraries and frameworks. I consider myself aware of the top frameworks in many languages, but I hadn't heard of any of these. That in itself showed me that the company was backed against a wall in hiring somebody.
Recently I've been seeing two opposing trends. On the one hand I see on sites like dice.com that the job market for IT is almost as hot as during the .com bubble. On the other hand I hear from scores of people saying that the job market is so tough and they can't find a job in IT. Then I skim the open jobs and I frequently see the combination of skills that they are looking for and sometimes it makes me queasy. Many companies have clearly painted themselves into a corner with the skills that they need to maintain their current operations and move them forward. This situation is a a result of prior architectural decisions.
I've worked with key frameworks and managed people learning new frameworks. Even with people from top schools, learning a new framework and using it well can take 6-12 months in some cases. Then there is the issue of maintenance. Frameworks seem to regularly be pushing the bleeding edge, which can be a problem. It feels sometimes like the incentive system for framework developers is different than the incentive system for developers at a given business. Many businesses are looking to get the software job done as quickly, securely, in as organized a manner as possible, in a way that is easy to maintain going forward. Grabbing a tool like a framework seems like a perfect solution. But the thing is, a software framework may be trying to stuff in every new buzzword and feature that comes out as fast as it comes out. This means that you are constantly forced to upgrade your OS, your programming language, your 3rd party support libraries, etc. in order to run the newest version of that software. Your application's code base may be very stable and maintainable at first, but the things it relies on as a foundation are migrating underneath you.
One case in which this worked out badly was at one of the nation's biggest hospital networks. They adopted a language and a framework for their platform. But the new versions of the language and the framework weren't compatible with the older versions of the framework and language, even though both the language developers and framework developers fully intended them to be and had worked to that end. Tens, hundreds of thousands of dollars were spent trying to get the upgrades to happen but in the end the hospital had to stay stuck in the past. Nearly a decade goes by and who are they looking to hire? Developers who can use a framework that was the flavor of the week X number of years ago, but not the most recent version of the framework for which there is documentation, but an older one for which there isn't much around any more. All the modern features of that language you learned in school, sorry, that won't run in the old environment. The whole environment feels like a house of cards that you hope won't fall down.
One thing my mind tends to consider when I see very specific skills listed in job postings is how many people get winnowed out as a result of that list of features. If you just need a Java developer, or a php developer, or .Net then maybe 10-20% of all developers know one of those things and can operate at a proficient level in whatever you need them to do. You have hundreds, thousands, maybe even 10,000 developers in any given city that are ready and willing to do that work for you. But what if you decided to use a (flavor of the week) framework that only 1% or 5% of developers with that skillset know how to use? And then you add in one or two similar limiting factors that only 1 to 5% of people in that language would ever use? You're trying to find a needle in a haystack person to support a set of tools that modern minds wouldn't choose to use. And there you are.
That being said, I think the worst-case scenario a company could find itself in is to have a legacy environment that is falling apart at the seams that never had anything but cowboy coders with no architectural thoughts putting together the architecture. So I admit, there is an even worse case scenario. On the other hand, it is also possible to just stick to the core programming language and have as few 3rd party libraries as possible, along with some good design patterns, and you have a maintainable application with a readily available labor pool to apply to it.
In the end I'm stuck where I started. I think anyone who suggests using a framework is using sound, professional judgement. At the same time, they may strategically be painting your company into a corner that it may not want to be in 10 years later. What's your take on this?
