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 pkimmel@softconcepts.com if you live in mid-Michigan and are interested in participating.


  • vague answers

    Posted by nickmalik on 07/01/2004 04:31am

    Your article raises some good points, and I agree with many of them. However, your conclusion appears too simplistic: "To build software ... companies will need to hire highly trained architects and specialists, invest in good upfront decision making, and delay gratification." Highly trained in what? You wouldn't want someone highly trained in waterfall models, would you? And what do you mean by "good upfront decision making?" Clearly, good decisions lead to good products, but that's like saying "we all have to eat" as a justification for french cuisine. And why delay gratification? There's no reason to prevent the user from seeing visible signs of progress, as long as the system can be developed using agile techniques. Simply having a GUI does not mean that a good architect will be short-circuited by the business manager! With test driven development, you can take the drive to instant gratification and turn it around. There is nothing more satisfying that watching all those little red dots in NUnit turn Green, one at a time, over the course of a day or two. Can't get more instant than that, and yet, it creates good, testable, reliable code. I don't disagree with where you are coming from, but where you are going just seems a bit vague...

  • no comment

    Posted by koo9 on 06/23/2004 06:45pm

    hmm... should we use vb for spacecraft control system? should we use assembly for simple accounting software?

  • I agree, however...

    Posted by Ken Varn on 06/23/2004 02:02pm

    Sadly, your article definitely has a lot of truth to it. We are in a culture of instant gratification, and as a software engineer, I have had to succumb to the very things that you mention in your article. As much as I would love to put together a blockbuster design before any coding is done, the reality is that my management group is sales driven and is looking for immediate tangible results. The time constraints do not allow for extensive up-front design to take place and the decision makers are not focused on design time benefits. However, I do feel that there are times when up front coding is necessary to prove or disprove a prospective design decision. I have found that with all of the technologies that are available and the demands that are required of software, that it is sometimes necessary to experiment with coding before the design is written. Namely to determine the feasibility of a concept before it goes into design. For example: We needed to develop a web browser GUI using ASP.NET. We were quite familiar with developing application level GUIs, but not browser based GUIs. Having a general idea on how we needed a screen to work, we set out to develop it under ASP.NET to determine if our requirements for screen look and feel could be satisfied. We did not want to put together a design and then realize that the assumptions were off base. Once we determined the browser GUI capabilities that we had at our disposal, we were able to create reasonable design time decisions. Without some up-front coding, a design may be too weak or have unresonable demands of the technologies available. Up-front coding, especially in uncharted waters, can help in finding out what is possible for the software before it is designed. This has nothing to do with instant gratification, it is purly investigative and necessary.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • For many organizations, moving enterprise applications to the public cloud can be a very attractive proposition, but planning the best way to move your applications is mission–critical. As an alternative to the costly option of re–architecting the application for a cloud environment, you can follow a "lift and shift" model that's significantly cheaper and almost always a lot quicker. In order to have a successful "lift and shift" migration, read this white paper to learn a few rules you should …

  • Microsoft® Office 365 is a top choice for enterprises that want a cloud–based suite of productivity collaboration applications. With Office 365, you get access to Microsoft™ Office solutions practically anytime, anywhere, on virtually any device. It's a great option for current Microsoft users who can now build on their experience with Microsoft™ solutions while enjoying the flexibility of a cloud-based delivery. But even organizations with no previous investment in Microsoft will find that …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date