Another Plea for Software Quality: Can You Hear Me Now?
Lou LaMedica runs the CPE (customer premises equipment) Evaluation and Development Lab for Verizon Wireless in Bedminster, New Jersey. In other words, if you want Verizon Wireless to make your mobile handset available to its 68+ million subscribers, you need to go through Lou and his staff of roughly 40 evaluation engineers.
Verizon Wireless’ CPE Evaluation and Development lab evaluates more than 100 handsets each year. As a result, LaMedica has noted the very sad state of software quality in today’s handsets. Lou is mightily concerned about the state of software quality today and he has a message for you, whether or not you design mobile phone handsets: Clean up your act. Now.
“Everyone struggles with this problem,” says LaMedica. “There’s no time to do what’s needed but plenty of time to fix it later. If manufacturers spent as much time on software quality as they do on hardware quality, there’d be no problem.”
It’s not unusual for LaMedica’s lab to get five or six software releases for a handset. “Everyone’s in the same boat,” he says. What’s needed, says LaMedica, is some sort of process. LaMedica notes CMU’s Software Engineering Institute (SEI) and its CMM and CMMI (Capability Maturity Model and Capability Maturity Model Integration, see this interesting report: CMMI or Agile: Why not Embrace Both!). “CMU has made the process more practical,” says LaMedica, “but like [the] Baldridge [Award], you can go broke doing it.”
According to LaMedica, the real issues are awareness and training. You start with an awareness of the problem. “It’s like drunk driving or seatbelts. You need to educate people” so they will embrace the idea of better software. “Why is this so difficult?” asks LaMedica. “You don’t need a college degree, just some rigor. We could resolve this issue in three years by applying hardware quality standards to software.”
To that end, LaMedica has been pushing software quality improvement in the annual TechFests that he runs for vendors aspiring to do business with Verizon Wireless. Last month at TechFest 2008, he invited Ellen George, an authorized SEI instructor, to talk to TechFest attendees about the experiences that SEI’s customers have had with software development process improvement.
LaMedica cited the book Winning with Software written by the prolific Watt S Humphrey as a resource for those aspiring to improve software development within their own organizations. Another action LaMedica advocates is the publishing of lists of people who provide quality improvement training for development teams. To that end, I’ll redirect you to my favorite software instructor Jack Ganssle and his entertaining DVD, which I reviewed previously (Boost Firmware Productivity Almost Without Pain—Betcha Won’t Do it! But You Should.).
Get up and go do something about this, now.
Jack Ganssle commented:
I think this economic meltdown, caused by companies packaging toxic assets and passing them off to others, is a good analogy to the software bug issue. Get it out now! It'll be someone else's problem. The sad reality is that if we can do a million line of code project in a month, next time they will demand a 2 week schedule to beat the competition.
The solution? There's the truth, which has been shown repeatedly: quality saves time. But there are limits to how much time can be saved. So furious activity, substituting for doing things right, gets rewarded.
The grim reality is that I think things will get worse until some disaster happens. Something really awful that is attributed to software. Legislation, regulation, certification and all those ills will be layered on the software industry in an attempt to get things under control.
We do build marvelous, amazing devices with firmware. Things do work surprisingly well considering how intolerant software is of errors. But software is unlike any human activity in all of history. In life most times a 90% is an A. In software that's an F. One wrong bit out of a million can be an utter disaster. It's time to recognize that software is different, and requires different approaches.















