Frameworks and the conjunction fallacy
Frameworks are great. After all, some helpful way to do X combined in some helpful way with some helpful way to do Y must be a whole lot more helpful than just a way to do X and just a way to do Y, right?
Wait a minute, anyone who has used a framework might say, what if someone wants to do Z instead of Y? Why, of course, say the framework "architects," we'll just provide a helpful way to help you choose helpful ways.
How helpful! Now not only do you have to know how to do X and how to do Y and how the framework helps you do X in a helpful way with doing Y, but you also need to know the helpful mechanisms behind letting you choose the helpful ways.
Clearly the original argument for helpfulness broke down somewhere. But where, and why?
The underlying fallacy behind the majority of software design today is the belief that computer systems can be "useful" and "helpful." Useful and helpful for doing what? For doing what they were designed to do. Stated in these terms it is immediately apparent that this mindset is a tautology. Completely useless as a basis for reasoning.
Is there a better way of thinking about software? Let's start by asking why. The entire motivation underlying our enterprise is the desire to accomplish X and Y. Each step we take can either bring us closer to that goal, or not. Given that time and other resources are finite, each step that does not bring us closer to the goal is "unhelpful" - it gets in the way of what we want to do.
I believe the right way to think about computer systems is as things that get in the way of what you want to accomplish. This way the goal of software design becomes not getting in the way of what you want to do.
Given this approach it immediately becomes obvious that the argument presented at the start of this post is simply a conjunction fallacy. Likewise many other "reasonable assumptions" about software that are not borne out by experience can be shown to be flawed a priori. Most importantly, this mindset helps prevent such "reasonable assumptions" from being taken up in the first place.
While this post debunked one of the arguments used to both justify the development of frameworks and their use, the decisions surrounding the latter are also driven by other logical fallacies, and, like the vast majority of human decision-making, by emotions. In a forthcoming post I will examine some of these factors.
[Major thanks to Ryan Holiday for providing the inspiration for this blog post.]
1 comment:
I don't think I can agree to your opinion on frameworks. What about frameworks like Ruby on Rails / Seaside? With these, I'm able to build fancy web (2.0 ;)) applications within just a few days of learning. I mean, you're probably right with the observation that often, frameworks require a lot of unnecessary "trivial" effort ("writing XML files"). But on the other hand, you also have to weigh it against the benefit you get from reuse.
(It's years ago when I last programmed Javascript and I completely lost track of the browser development, yet I can build a web app with such a framework. How can this be a bad choice? I'd need weeks to learn all the expertise that this frameworks provides me for free.)
However, good article. It always helps me to reflect on things like that, even if I don't completely agree. ;) *Subscription added*
--Günther
Post a Comment