I have been thinking recently about software and product quality. There is a software quality conference this fall here in the Pacific Northwest and I recently read an article on the top ten software blunders of the last decade. As we rush products to market, are we compromising quality? What negative effect does that have on our product? Is it worth it? Is it acceptable? Is it the price we pay for doing business in a hypercompetitive world?
Continuous Exploits
In late April, it was discovered that there was yet another hole in Internet Explorer that allowed hackers to exploit vulnerabilities and plant malicious code on individual computers via infected websites. This is just one example of applications and operating systems with bugs waiting to be exploited. My question is this—are product developers and quality assurance teams releasing inferior, not-yet-ready–for-prime-time products, or are the products so complicated that developers do not understand all of the implications until after they have been tested by consumers? If it is the former, then the answer is to wait until all of the bugs are detected and corrected to release a superior product. If the answer is the latter, then that means that you and I are paying for the privilege of being product testers. Personally, I can think of better things to do with my time and money.
A Simplistic View
I will admit that I may be taking a simplistic view. My experience runs towards hardware products and support, although there are still quality products in that arena as well. According to Microsoft, Windows XP, which was released in 2001 and recently became unsupported, was compiled from forty-five million lines of code. Thirteen years later we have Windows 8.1. How many lines of code are in this operating system? Is the complexity sustainable or are we building products that we cannot manage? With this increasing complexity, have we resigned ourselves to a certain number of acceptable bugs? What is our tolerance level? One percent of nonfunctioning or potentially compromising code? Is that acceptable?
Thoughts
Nineteenth-century writer Oliver Wendell Holmes once said “I would not give a fig for the simplicity on this side of complexity, but I would give my life for the simplicity on the other side of complexity.” I believe that we are stuck in the middle of that complexity right now. While our products are sophisticated, they lack that elegance on the other side of complexity. We have learned to write incredibly complex code, which is understood in part by individual coders but in entirety by no one. This is the very thing that makes that code vulnerable to exploits and security breaches. If we could somehow find that simplicity or elegance on the other side of complexity, then we could enjoy robust, secure, and usable products.
Do you have or use a product or application that you think has broken through that complexity curtain? Share your find with me.
About Kelly Brown
Kelly Brown is an IT professional, adjunct faculty for the University of Oregon, and academic director of the UO Applied Information Management Master’s Degree Program. He writes about IT and business topics that keep him up at night.
