Vladimir Sedach

Have Emacs - Will Hack

April 15, 2009

Problem-solving is hard, let's go write XML configuration files

Topic: Software engineering

Previously I blogged about why the premise behind software frameworks turns out to be a logical fallacy. This post will continue the attack on the framework cult by examining the reasons why people continue to believe in the myth of increased productivity through frameworks.

Frameworks offer people a misleading sense of comfort through the avoidance of uncertainy.

Consider carpentry tools. How do you use them? What do you use them to accomplish? Now consider a toy construction set such as the Erector. The toy construction set offers you a path you can follow to arrive at some cool artifact, even if you do not know exactly what you want to do. The construction set can offer this security because it limits what you can accomplish, and how you can accomplish it.

According to Buddha, ignorance is the root of all evil. According to Christian tradition, people are inherently evil. It is then no surprise that most of the time most people do not know what they want to do. Finding out "what" is hard, requiring a lot of time and learning. It is a lot easier to write XML configuration files instead.

There is a misguided comfort that comes from knowing that you did a day's worth of honest work. It does not matter if what you are doing is leading you down the wrong path, because with a framework you are at least accomplishing something, even if that something will not bring any value. As a manager who decides to use a particular framework, you are in effect acting as a proxy sales agent for the party promoting that framework - selling your customer a solution that may not be in line with your customer's goals.

Many logical fallacies go into the typical software development decision-making process. Frameworks in particular are notoriously prone to the bandwagon effect (how many "enterprise" web-development frameworks for Java have come and gone and with what ridiculous frequency?). Any person held responsible for the consequences of a decision will be prone to post-purchase rationalization (remember that before a person tries to sell a methodology to his organization, he has to have been sold on it her/himself), so the bandwagon effect is frequently used as an argument for adopting a particular framework. In addition, nebulous terms such as "enterprise" (which, because of its strong association with frameworks, has almost universally acquired the definition as "verbose junk" in the software development world) somehow end up in place of well thought-out arguments and evidence.

People who become experts at particular frameworks can quickly develop certain kinds of applications. This is not an inherent property of that particular framework, or of the fact that a framework is being used. This is because those people have spent the time becoming experts. What technologies do you have expertise in? What domains do you have expertise in? Do the applications offered as examples have anything in common with the problems you are trying to solve?