Uncle Bob 11 May 2014 Craftsmanship Frameworks are powerful tools. We'd be lost without them. But there's a cost to using them.
The relationship between a programmer and a framework is similar to the relationship between an executive and an administrative assistant. The framework takes care of all the necessary details, so that the executive can focus on high level decisions.
Think of Rails, or Spring, or JSF, or Hibernate. Think about what writing a web system would be like without these frameworks to help you. The idea is disheartening. There'd be so many little piddling details to deal with. It'd be like endeavoring to construct a mnemonic memory circuit using stone knives and bearskins[1].
And so we gleefully use those glittering frameworks. We joyously intermingle our code with the frameworks' in anticipation of all the benefits they promise. We make the mistake that so many executives have made before us. We marry our secretary.
Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. Of course this seems like a good thing; and it usually is. However, there's a trap waiting around the corner; and it's hard to see it coming.
The framework smiles prettily at you, and entices you to move in closer. It promises conveniences galore in return for a little coupling. Step by step it leads you down a pathway you had thought you'd never travel. Before you know it you find yourself engaged in all manner of unnatural acts, inheriting from it's base classes, relinquishing more and more of the flow of control, bowing ever deeper to the framework's conventions, quirks, and idiosyncrasies.
One day you wake up in Vegas to the realization that you are married. You didn't want to get married. You don't remember speaking the vows. But there's this golden ring that surrounds your code; and you realize it's a wedding band. Your code will never escape from it's clutches. It's got you. You are framework whipped.
But there's no golden band around the framework. Indeed, the framework has made no commitment to you at all. That framework is free to evolve in any direction that pleases its author. When it does, you realize that that you are simply going to have to follow along like a faithful puppy.
And then, at last, you look around you and see that you aren't the only puppy on that leash. The framework has gathered a harem of software projects that have committed to it, without ever getting a reciprocal commitment in return. The roles have been reversed. The framework wields the power of life and death. Your code is just an obedient concubine.
OK, that was a bit hyperbolic. But only a bit. Getting trapped into frameworks is an all too common occurrence in software teams. They begin with rampant enthusiasm and willingly couple their code to the framework, only to find, much later, that as the project matures, the framework gets more and more in the way.
This shouldn't be surprising. Frameworks are written by people to solve certain problems that they have. Those problems may be similar to yours, but they are not yours. You have different problems. To the extent that your problems overlap, the framework can be enormously helpful. To the extent that your problems conflict, the framework can be a huge impediment.
Remember that frameworks are written by people, and people have their own agendas. One of the items on such an agenda is to get you to use their framework. As an author of past frameworks I can tell you that the more people who used my frameworks, the better I felt about myself. A lot of my self-worth got tied up into the acceptance of my frameworks.
Now I don't want to get too deep into the psycho-analysis of framework authors. Framework authors are not bad people. Indeed, for the most part, they are heroes. Many unselfishly release their code to the open-source community. Were it not for these people, our programming lives would be far less enjoyable and productive.
I've made this point about authors because it helps me understand some of the mechanics of the relationship between framework authors and framework users.
Framework authors will go to great lengths to entice you into the fold. They'll write papers and give talks. They'll provide examples showing you how to bind tightly, ever tightly to their code. They'll demonstrate all the benefits that tight binding gives you. They are convinced that their code can help you, and they work hard to convince you too.
That's perfectly normal, and not at all dishonorable. They want you in the fold.
Once you are in the fold, however, their interest in you might change somewhat. Here's a picture of one famous framework author telling his users what he thinks about some of their concerns. (R rated)
Over the years, I've adopted a healthy skepticism about frameworks. While I acknowledge that they can be extremely useful, and save a boatload of time; I also realize that there are costs. Sometimes those costs can mount very high indeed.
So my strategy is to date frameworks, but not to marry them. I keep frameworks like Spring, Hibernate, and Rails at arm's length; behind architectural boundaries. I get most of the benefit from them that way; and I can take ruthless advantage of them.
But I don't let those frameworks get too close. I surrender none of my autonomy to them. I don't allow the tendrils of their code to intermingle with the high level policy of my systems. They can touch my peripheral subsystems; but I keep them away from the family jewels. My business rules are out of bounds to the frameworks. The high level policies of my systems shall never be touched by frameworks.
My systems will loosely hold a harem of frameworks! Those frameworks will be my concubines to be enjoyed on my terms. My systems will not succumb to their charms to become one of their willing slaves.
After all, I may find that my systems, and a framework they use, evolve irreconcilable differences. I want the separation to be quick, decisive, and to hurt me as little as possible.