The Taste of Quality is Long Remembered
There is a restaurant located halfway between Boston and New York City, 90 miles from Fenway, 100 miles from The Carnegie Deli. To anyone who regularly travels the Boston/NYC corridor, this restaurant is a way station for the weary traveler, an oasis of pastrami, pickles, and knishes, a beacon of hope that comes into view just as you’re starting to lose steam, and satisfies your hunger to speed you on your way.
The feeling of happiness that envelopes you as the “Rein’s Deli, Exit 65” sign comes into view is nothing short of coming home after a long day of work. Bus tour operators plan itineraries to include a stop at the deli. Professional wrestlers—mortal enemies only hours earlier—dine together at Rein’s formica counter on their way home from the Boston Garden or Worcester Centrum. When the original deli burned down in 1991 and had to move across the street into the old Kathy John’s, my folks, who were living in Europe at the time, read about it in the International Herald Tribune. Rein’s Deli, an international story…
How could this little restaurant in suburban Hartford, really nothing more than a knockoff of famous New York and Atlantic City delis, have become such an icon? To be sure, location had something to do with it—you can’t discount the correlation between distance traveled and hunger. But only three miles further and you’d be in roadside restaurant heaven: Uno’s, Chili’s, Outback, Macaroni Grill, John Harvard’s, and the ever popular Cracker Barrel. Yet it is Rein’s Deli that has travelers coming back time and again.
I believe this loyalty boils down to one thing: quality. The food is always good, the service always quick (even when the line is out the door on a Sunday morning), and the prices always fair. Bernie and Bob Rein, owners and proprietors since 1972, had two slogans that summed up their philosophy:
- “The taste of quality is long remembered”
- “Never skimp on quality or quantity; raise the damn price if you have to”
I worked my way through college doing weekend grill duty at the deli. Can’t say I loved the job, or that I use my short-order cooking skills much anymore. Still, nearly 25 years later, I remember Bernie and Bob’s slogans and regularly use them when urging IT organizations to improve their quality. And I still go back to the deli for breakfast or dinner when I’m in the area.
The Bad Taste of Poor Quality is also Long Remembered
People will forget when a project comes in late, as long as it’s not too late. People will forget when you go over budget, as long as it’s not by too much. People might even forget that you delivered less than they asked for, as long as what you give them solves their needs. But people will never forget, let alone forgive, when you deliver a poor quality system that makes their job more difficult.
The urgency of improving quality seems so obvious, yet organization after organization is drowning in the backwash of sloppy development. Poor quality costs the company in many ways:
- Rework: drains resources away from more important development activities, resulting in higher operational costs and reduced output
- Workarounds: users are forced to do extra steps to make up for gaps in system functionality
- Poor system performance: outages are the visible result of quality problems; more insidious are the subtle inefficiencies that sap CPU cycles and ultimately lead to higher infrastructure costs
- Errors: probably the most dangerous result of poor quality code, logic errors are difficult to uncover and can have far-reaching ramifications if they impact the customer or financials directly
- IT oversight: poor quality reduces management confidence, increasing administrative burden as IT is called to reckoning by more-and-more stakeholders who are suffering from poor system performance
Conventional wisdom says that it costs 10 times more to fix a bug in production than fixing it in development. A production bug must be treated like any other change request, only more urgent. It must be scheduled with the change control board, reviewed for requirements or design flaws, checked out of the SCM system (hoping that no one else has locked down the code), fixed, unit tested, integration tested, user tested, staged, and redeployed. Even if the work to fix the bug is nominal, the operational overhead associated with good release management still consumes much of the capacity that could have been used on new functionality.
Put another way, for every 10 bugs caught before production, you free up capacity to do nine more units of new development. To frustrated business partners, this is a double indignation—they’re paying twice for each unit of low quality output, and getting fewer units of what they asked for. Not to mention the negative impact these bugs are having on business operations.
Measure Your Way to Better Quality
No other metrics raise the hackles of developers more than those that measure quality. Not because they don’t appreciate the importance of better quality, or aren’t trying to improve the quality of what they produce, but rather because no matter what they do, the bugs just keep on coming.
IT organizations that wish to renew their focus on quality must return to the basic tenets of software development:
- Better testing
- Better SDLC process
- Better design
- Better source code management
Better testing, or more specifically, increased focus on testing, will force the team to build better test cases, better use cases, and ultimately, better requirements as the folks responsible for quality look for ways to improve their testing efforts. This will put pressure on developers to improve the code, leading to better design, better architecture, and ultimately, a better software delivery process.
It isn’t easy to put a dollar figure on poor quality, but organizations should go through this exercise nonetheless. For though you may come up with as many different analyses as there are stakeholders, the value of the exercise is in gaining a better understanding of where your processes are failing, and taking steps to improve your system’s quality.