Drinking Hemlock, or, Why Instant Gratification Is at Odds with Software Quality


Socrates kept giving everyone his opinion and then they made him drink Hemlock. But, Hemlock is harder to come by and we have a few more laws that may postpone my having to drink Hemlock for a few more years, so here goes.

The U.S. is a society of instant gratification. Instant gratification is as ingrained in our culture as much as Hollywood, SOBE, hip hop, Kid Rock, and gas-guzzling SUVs (of which I am a proud but recently poorer owner). It is no wonder that this innate attribute of Americanism bleeds over to software development; it does.

When we build software in the U.S., whether you are a denizen or visitor, we are compelled by the current culture to write code first and think later. Has this scenario every happened to you? You are trying to create a good design and a manger asks “where is the GUI?” Or, my favorite all-time quote is “I am not paying you to draw pictures!” (That company and its manager are in the ash heap of history, fortunately.)

It is this neurotic penchant for instant gratification that is leading to the huge percentage of software projects that fail. I will tell you why.

Gobject Oriented Programming

A Gobject is a GUI object that encompasses everything from controls to business logic. Gobject Oriented Programming, or GlOP, is code that arises from a composition of a solution from the perspective of the GUI and little else. The theory is two-fold: If you put all of the controls on a GUI, you just need code to move the data, and if you don’t create screens, how is any non-technical person—read, those with the checkbooks—supposed to know you are making progress?

GlOP is the weakest kind of programming and leads to the worst kind of schlock code, but event smart, rational programmers and managers are wont to delay GUIs and gratification because doing so is very risky. Customers don’t get excited about UML models, patterns, refactoring, or even good clean code because they are not tangible to these non-technophiles. The theory goes that if you are not producing something tangible from the perspective of the viewer, you are not doing any useful work. This is so not innately human and so obviously goes against rational thinking that it defies explanation, unless one remembers people are not rational. We are not Vulcans.

The first rule of sales is that people buy on emotion and GUIs are emotional; models and lines of code are not. Perhaps we need to jazz up UML models with color and more pictures to make them tangible.

Why Reducing Cost of Ownership Is a Terrible Argument

Everyone talks about reducing the cost of ownership, but no one really cares.

It is a well-documented fact that good design, patterns, and refactoring can reduce the total cost of ownership (COO) and that these long term COO costs are significantly greater than initial development costs, but no one cares. The reason they don’t care is because these ownership costs are not being paid right now, and cost of ownership is a rational, technological argument that does jive with instant gratification. Consequently, we talk about COO but are not willing to delay the gratification of now for the gratification of later.

Exacerbating the GUI-now mentality is that many programmers and managers will never pay the COO. They will move onto something else, often before the current project is completed, so protecting their job at this point in time requires that they succumb to the GUI-now mentality.

This is all very short sighted, but that is the mode we are working in—the here and now. If a manager insists on doing GUIs first and a programmer’s immediate income is in jeopardy, the programmer will in essence permit the manager to shoot themselves in the foot. Who pays? The consumer, because this schlocky software is foisted on them and the originators are long gone by the time the customer actually sees the blue screen of death, suffers Adware constipation, or loses their shorts due to a virus. Unfortunately, the customers are culprits because they demand to be satiated now.

Managers insist on GUIs as proof that they and you are doing something. You know you shouldn’t create GlOP, but your income is threatened, and the insidious tango ensues.

Why Architecture, Design, Patterns, and Refactoring Aren’t Used Universally

A manager who had become a manager by attrition once told me that he wasn’t going to pay me to draw pictures (meaning UML models). That company is now defunct, and I am both gratified and sad. I am gratified because that sort of stupidity should not be rewarded. I am saddened because many people lost their jobs, and a conceptually good idea never made it to market.

From the manager’s perspective, I understand too. The company received several million dollars during the .NET bubble, but all of the developers left because they knew they were on a death march. The remaining programmer-cum-manager knew his immediate income was in great peril unless he showed results, results being a GUI. He and the other non-programmers ultimately lost their jobs, but who really lost? The people who invested millions in this startup.

How could such a thing be permitted to happen? Hubris. A salesman had a good conceptual idea, but thought an ability to sell was the same thing as being able to direct software development. He was wrong. The manager thought he could bully people into working harder, and he was wrong.

While people are not rational by nature, building good software is both rational and irrational. It is necessary to create a good presentation layer to feed the user’s desire for emotional gratification, but it is impossible to build good software without making good rational trade-offs. Skipping design is not a good, rational trade-off. Skipping design and being ignorant of patterns and refactoring is terrible complacency.

The key here is that, in my tale, the rats (programmers) all left the ship because they knew it was sinking.

Employing a competent architect who knows about the UML and how to design is critical. The fact that architect should know about design patterns and refactoring is also critical. Ignoring these basic premises will most likely be fatal.

Pervasive Ignorance

How can this state of affairs persist and be permitted to be perpetuated? The answer is that the UML is only a half-dozen or so years old, design patterns are relatively new, and William Opdike only introduced his theory on Refactoring in his dissertation in 1990. This means that most gray-haired people only have had the last few years to master these subjects and have never had the opportunity to employ them in the trenches. That is, they do not understand or know about them body and soul; they are ignorant of them.

Why RAD Is Bad

R.A.D., or Rapid Application Development, should be re-dubbed R.A.P., or Rapid Application Prototyping. (Ironically, enough the amount of design effort employed with RAP is consistent with the average amount of effort that seems to go into writing rap lyrics. I like good rap, by the way, so no flame-mail please).

RAP more appropriately rhymes with crap, which is what the quality of most RAD applications is. Prototyping is not about quality; it is about feeding emotional gratification. Slap together a prototype to show that something can be done, to show your customer your ideas in a way that is tangible to them, and then throw it away. Unfortunately, too often rapped together prototypes are deployed. The reason is that if GUIs are a sign of progress, throwing them away is wasteful. I hate to be too cynical, but a goofy emotional argument seems to be that our need for immediate gratification feeds into a twisted sort of protestant work ethic.


The net effect of needing signs of progress now is that a lot of bad software is being built, or worse, a lot of bad software is almost built and deployed. A large percentage of projects are failing at huge expense. Naturally, companies are attacking this problem, but in the wrong way. Companies are outsourcing to reduce labor costs, but they are addressing the smallest symptom and the one least likely to succeed: labor costs.

To build software successfully, reliably, and that is useful to real people, companies will need to hire highly trained architects and specialists, invest in good upfront decision making, and delay gratification. Sadly, this not the current trend. Pass the Hemlock.


Paul Kimmel is the VB Today columnist for codeguru.com and developer.com and has written several books on object-oriented programming, including the recently released Visual Basic .NET Power Coding from Addison-Wesley and the upcoming Excel VBA 2003: Programmer’s Reference from Wrox Press. He is the chief architect for Software Conceptions and is available to help design and build your next application.

Grammatically, I may be a poor writer but I attribute my desire to write to Dr. Baughman and Ms. Montgomery, team teachers at Jefferson Community College in Louisville, Kentucky. Their inspired passion is close to divine. They used to teach a joint English and History course. Although I may have been their poorest student, their course was the best I ever attended.

The Lansing, Michigan area has started a new .NET Users Group. A well-run group offers great learning and networking opportunities and occasionally some free pizza and door prizes. Contact me at [email protected] if you live in mid-Michigan and are interested in participating.

More by Author

Must Read