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.
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:
- If you put all of the controls on a GUI, you just need code to move the data.
- 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.
Why Architecture, Design, Patterns, and Refactoring Aren’t Used Universally
Remember the manager who told me that he wasn’t going to pay me to draw pictures (meaning UML models)? His company is now defunct, and I am both gratified and saddened. 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.
I understand the manager’s perspective too. The company received several million dollars during the dot-com bubble, but all of the developers left because they knew staying with the company amounted to 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 happen? Hubris. A salesman had a good conceptual idea, but thought the 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.
The key to this story is that the rats (programmers) all left the ship because they knew it was sinking.
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 (irrational) 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.
Employing a competent architect who knows the UML and how to design is critical. In fact, the architect should know about design patterns and refactoring as well. Ignoring these basic premises will most likely be fatal.
How can this state of affairs persist and continue to perpetuate? The answer is that the UML is only a half-dozen or so years old, design patterns are relatively new, and William Opdike introduced his theory on refactoring only 14 years ago. This means that most gray-haired people have had only the past 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
Rapid application development (RAD) should be re-dubbed RAP for rapid application prototyping. (Ironically, the amount of design effort employed in RAP is consistent with the average amount of effort that seems to go into writing many rap lyrics. I like good rap, by the way, so no flame-mail please).
RAP more appropriately rhymes with crap, which is the quality level of most RAD applications. 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 tangible way, 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.
Pass the Hemlock
The net effect of this need for immediate signs of progress 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 financial losses. Naturally, companies are attacking this problem, but in the wrong way: outsourcing to reduce labor costs. They are addressing the smallest symptom and the one least likely to be a cure: labor costs.
To reliably and successfully build software that is useful to real people, companies need to hire highly trained architects and specialists, invest in good upfront decision making, and delay gratification. Sadly, this is not the current trend. Pass the hemlock.
Paul Kimmel is the VB Today columnist for CodeGuru.com and developer.com. He 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. They taught a joint English and History course. Their inspired passion is close to divine. 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@example.com if you live in mid-Michigan and are interested in participating.