Sorry about the hiatus. I've been busy setting up my own company and it's running now. Today's topic is a difficult one: I'll try to describe the problems of frameworks in software production and how I think a "tool" is often a better way to raise productivity and quality.
What is a framework in general? In construction I'd imagine it to be something akin to a mold, something that sets many of the properties and dimensions before we even start the work. As long as you know these properties and dimensions, you're safe and you can apply the framework to save time and increase quality. I'd say the same semantics apply for software frameworks. They set some properties and dimensions of the software artifact when you decide to use the framework in question.
As long as a framework is relatively small with few properties and dimensions, I see no problem. You'll soon memorize the properties and can easily judge if using the framework is a good idea or not. But even initially small and simple frameworks tend to grow more and more complex either from the pressure of the userbase (OSS) or from the pressure to resell the same thing for the tenth time to the same customers (commercial products). Spring is an excellent OSS-world example of this. At it's very first versions, I thought it was brilliant and simple - more like a tool than a framework really. When I look at Spring now, it feels like holding James Joyce's Ulysses in my hands. And Spring isn't even worst of the frameworks, it's actually pretty good.
There are frameworks for everything these days. The useful ones are usually ones that simplify some technical aspect of software engineering, like UI-frameworks or frameworks for transactional components or frameworks for persisting data. The ones that cause usually more problems than they solve are the ones that try to venture in the non-technical problem space of software engineering. So you're planning to create a system for handling resources in your company? Not to worry! There's a plethora of amazing ERP-frameworks that only need a tad of configuration and you're done! Not.
The illusion here is that while many problems in software engineering resemble each other a lot, like ERP or CRM or information publishing (CMS), I've rarely seen a company actually adapt to the properties and dimensions the framework they're building things on. The thing most CTO's are missing is that if you choose to use a generic framework for CRM, you'll have to be prepared to modify the organization and processes of the company to adhere to the rules of the framework.
From the programmers perspective, frameworks generally suck. In the time it takes to understand all the rules and dimensions of the framework, a good programmer with good tools is usually done with the original requirement. And what happens when the requirement doesn't neatly fit in any of the available properties of the framework? Cludges, hacks, hours and days spent trying to circumvent the bloody thing.
Ok, enough raving about how frameworks suck. Tools - those I like. Why?
Let's consider a hammer, one of my favorite concrete tools. It's small, very simple and doesn't take long to understand how it works. You grab the other end and hit something with the round end or use the other end to pull off nails. But there's more. Once you learn the simple properties of the hammer well (after all, there aren't that many of them), you'll start to use it in more novel ways. For hitting other tools, for breaking concrete, adjusting a heavy shaft, heck you can even use it to forge steel.
A software tool is something similar to a hammer for me. It has one clearly defined purpose of use, for example to create XML-based REST-services with plain old java without external configurations. How does a tool differ from a framework here, you must be asking. A tool doesn't force you to any particular style of REST-services; a tool doesn't abstract away the Servlet API nor HTTP-protocol; a tool doesn't force you to change your architecture if you decide to use it; a tool lets you adapt it easily to better fit your need. A framework doesn't have these qualities.
I seem to be developing an undercurrent running through all my blog posts. Here it is again: It takes an experienced and courageous architect to decide against using massive frameworks. Sure, there are architectures that are a perfect fit for framework X, but only after coming up with the architecture without using a framework as a crutch. A good architect always first starts with a clean table, trying to imagine the simplest possible solution that would fulfill only the known requirements and nothing more. It's easy to add more complexity to that, but extremely hard to remove unneeded complexity afterwards.
The lesson here, if there is such, is to be prepared to sometimes take a few steps back in your work and try to think as the great minds in our field did 30 or 40 years ago. Sometimes it's the correct solution to create a tool for the task you're doing. Think of the Unix-philosophy where there are dozens of small clearly defined command line tools. They're still used and useful and, although I might not agree, I know people who think there isn't a problem in software engineering that couldn't be best solved by combining a bunch of Unix-tools in a creative way.
