TANSTAAFL

Science fiction writer Robert Heinlein's truism, which applied to life on the moon in his classic novel The Moon is a Harsh Mistress, is also a key piece of advice for those engaged in application development and the processes surrounding the building and management of enterprise applications. The acronym stands for "There Ain't No Such Thing As a Free Lunch," and in my mind has always referred to the tradeoffs that an application developer makes in writing code.

It was a classic that I used extensively while teaching computer science. There is no single best way of doing anything in software development, I explained to my introductory classes. Rather, different approaches offered different benefits and limitations. It was part of their job as fledgling developers to determine what characteristics of an application were important to them, and to make choices that optimized those characteristics while minimizing the limitations.

It is a concept that doesn't sit well with some. Those seeking a cookbook approach to writing code, or those without the ability to judge and balance the relative merits of decisions leave early on in the degree program to attempt other pursuits. On the other hand, those who intuitively accepted that they made tradeoffs with every line of code tend to comprehend the other aspects of application development easily.

Observing this behavior is what led me to believe that the ability to understand tradeoffs and instinctively make the right choice in writing code was the mark of a good developer. You can see the result of the choices they make in the running application—fewer bugs, better performance, and even less code overall.

But the concept of TANSTAAFL also goes beyond coding. The fact of the matter is that no IT solution, whether it is a server operating system, a local area network, or application, is the single best solution for all, or even for a few. Any solution, no matter how desirable, will have unwanted characteristics that make it less than optimal.

While most of us understand this without even thinking about it, it's important to realize that those we work with, especially those with only peripheral responsibility for application development, might not have the same appreciation for the compromises that must be made to build and deploy an application.

For example, one of the advantages of commercial enterprise applications, such as SAP, is that they can (and in most cases must) be customized to meet the unique needs of an organization. This makes it possible to adapt the software to unique processes and specialized data used in the conduct of business. The downside, of course, is that customization takes time, skill, and money. And one of the byproducts of the flexibility that arises from being customizable is complexity.

But many of our masters believe that an investment of several million dollars and a year or more of custom software development means that all needs have been addressed in the most effective and convenient manner. The fact of the matter is that compromises were most likely made during the entire process, resulting in an application that works for the most part, but has limitations that make it useful but flawed. This is likely not the fault of the designers or developers, but rather the result of tradeoffs they all made to get the best out of the limitations they faced.

All of us advise the decision-makers in our organization. Some of us might even get to make decisions of some importance. Excluding the content, the best advice we can deliver is TANSTAAFL. Our applications will never turn out ideal, because there ain't no such thing.

Posted by Peter Varhol on 11/28/2004