Drinking Hemlock, or Why Instant Gratification Is at Odds with Software Quality, Page 2
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 resultsresults 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.