March 2, 2021
Hot Topics:

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

  • By Paul Kimmel
  • Send Email »
  • More Articles »

Socrates kept giving everyone his opinion until they eventually made him drink hemlock. Today, 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 I'm going to get something off my chest.

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

When we build software in the U.S., whether you are a native or a visitor, we are compelled by the current culture to write code first and think later. Has this scenario ever happened to you: you are trying to create a good design when 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. More on that later.)

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 (GlOP) is code that arises from composing a solution from the perspective of the GUI and little else. The theory is two-fold:

  1. If you put all of the controls on a GUI, you just need code to move the data.
  2. 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 it leads to the worst kind of schlock code. Yet even smart, rational programmers and managers are unlikely 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 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 reasoning so obviously goes against rational thinking that it defies explanation—until one remembers that 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.

Why Reducing Cost of Ownership Is a Terrible Argument

Everyone talks about reducing the cost of ownership (COO), but no one really means it.

It is a well-documented fact that good design, patterns, and refactoring can reduce the COO, and that these long-term COO costs are significantly greater than initial development costs. But no one cares, because these ownership costs are not being paid right now and COO is a rational, technological argument that doesn't jibe with instant gratification. Consequently, we talk about COO but are not willing to delay the gratification now for gratification later.

Perpetuating the GUI-now mentality is the fact 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 himself in the foot. Who pays? The consumer, because this schlocky software is foisted on them and the originators are long gone by the time customers actually see the blue screen of death, suffer adware constipation, or lose their shorts due to a virus. Unfortunately, the customers are also 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.

Page 1 of 2

This article was originally published on June 23, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

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