Product quality can make or break a company. Unfortunately, in software, most companies not only fail to deliver a quality product to their customers, but also fail to understand the attributes of a quality product. High-quality software requires more than a lack of bugs: it must effortlessly satisfy a user’s needs with a minimum amount of training.
This article discusses the attributes of high quality software examining real-world successes and failures and how product quality has helped or hindered companies.
Software Quality in the Real World
High-quality software meets both user and business requirements. User requirements include needed features, good performance and efficient workflow. Business requirements include on-time and under-budget delivery. Most financially successful products must balance these requirements. Delivering a product that has a poor workflow or inappropriate or buggy features virtually guarantees commercial failure. Likewise, delivering a high-quality user experience by breaking a corporate budget virtually guarantees that the company will not be able to recover the costs of development.
Companies with name recognition, market power or monopoly control can produce financially successful late products with buggy features and poor user experiences. Ironically, this is why new market entries rarely gain market share by producing products that mimic those of the leaders: leaders are not required to deliver high-quality products for success.
The staggering success of Apple’s iPod, iTunes and online music sales strategies demonstrates how high-quality products that target real users’ needs can not only take on market leaders but can soundly defeat them.
These products perfectly meet user and market demands without sacrificing user experience or quality by adding irrelevant features such as support for windows media formats (WMF), digital rights management (DRM) and non-Apple hardware. Apple’s perfect storm of hardware, software and content for the right price not only ensured, but was required for, market success while all other vendors struggle. In addition, Apple has been able to execute a strategy of continual improvement of their product line providing a moving target for those who are trying to play catch-up.
Categories of Quality
Modern development techniques divide quality into two broad categories : external and internal quality. While external quality measures the value of the end user experience, internal quality measures how well the development of the product can meet time and cost constraints.
Software organizations often fail to identify which category of quality is deficient in a broken product. This failure makes it nearly impossible to correct the deficiencies. This section examines the two categories of quality and how they effect the final product.
External Quality
External quality measure the value of a product to a user. External quality has two aspects: perceived quality and workflow.
Most organizations understand perceived quality. Perceived quality measures the reliability, performance, and stability of a software product. Perceived quality is specific to a problem. For example, acceptable performance and reliability of a Web-based application to determine the interest rate for a consumer inquiring about a loan will probably not be acceptable for a customer service representative processing thousands of loans per day.
The second and more important aspect of external quality is how well a software product solves a workflow problem. In addition to performing its advertised feature set adequately, an application must make the users’ job easier, faster and more reliable. This means that all applications must consider the target market and probable use to determine external quality. Many fast, reliable products are useless to customers because the perform functions that are not altogether useful.
The quality of an application for a particular workflow is not only a function of the delivered features but also how the UI exposes those features. UIs must clearly and immediately communicate the actions a user must perform next. It is extremely rare that “flexible” user interfaces designed to satisfy a largest number of customers and markets are of high quality. A brilliant discussion of user interface and workflow can be found in Mullet and Sato 1.
Most organizations confuse quality assurance (QA) with high-quality products. QA organizations only measure quality against product specifications. The burden falls on business and marketing organizations to determine proper feature selection. Too many features are just as deadly as too few features.
In the Apple media example, Apple was successful because its business analysts understood precisely how people want to use media: download easily, transfer between many personal computers, and play on portable devices. Users do not care about content format, record company negotiations or media business models. Apple satisfied its customers by eliminating user experience damaging features such as DRM and copy restrictions and including fast data transfer to iPods via firewire, creating easy to use hardware and software that always work and rarely crash. Apple’s dedication to stable international standards such as MP3, MPEG-4, Firewire and USB made the development much easier.
On the other hand, Microsoft media has included difficult technologies such as DRM and its own proprietary music format, WMF. In addition, Microsoft does not usually adopt International standards. These decisions were not made for the benefit of its customers, but as concessions to the recording industry and a desire to own all content delivery on the Internet. These decisions created a highly volatile environment forcing frequent upgrades of software, OS, and hardware as newer, incompatible formats are released.
Internal Quality
Internal quality measures how easily a program can be changed without breaking existing features. Changes include bug fixes, new features and existing requirements. Internal quality is directly related to the quality of design and the appropriateness of the programming language given a program’s size and domain.
Low internal quality makes it impossible for developers to predict the amount of effort required to add a new feature. In addition, changes will likely cause new, unexpected bugs. Low internal quality makes changes exponentially more expensive. As the cost for adding features increases, products get delayed and more buggy. These costs eventually overwhelm any value the product may provide. My previous article, “Software Project Failure: The Reasons, The Costs” discusses the implications of exponential costs on project success.
External quality is essential for customer adoption of a product. Internal quality ensures that a company can maintain its market lead and continue to deliver excellent software. Apple made an initial splash with excellent software/hardware with the iPod, iBook and PowerBook series. They made a killing by continually evolving the software and hardware to add new services its customers desired without breaking existing features. Most good competent companies can make that initial release and splash. Only companies that maintain a high degree of internal quality can continue to keep its customers happy.
Interdependance of Quality
Poor internal quality leads to poor external quality as new features and bug fixes create new, unexpected errors. In contrast, high internal quality leads to easy bug fixes and extensions.
Low external quality means developers create designs and code around incorrect assumptions. No matter how careful they are, the result will be disastrous as all code built on these assumptions will be wrong.
High external quality means that the assumptions the code is built around are correct and well understood. Hence, the developers are more likely to create extensions that are correct.
The relationship is not necessarily clear. Poor internal quality can be replaced by extraordinary effort on the part of engineers to create a decent product. These efforts are, in general, not maintainable. This is why early versions of a product may be of high quality and on time, but subsequent versions get later and more buggy. In the push to get the product out the door, developers let internal quality suffer. As internal quality degrades, development takes longer.
Since low internal quality creates exponential cost of change, it is very expensive to correct. Most code bases with low internal quality must be completely rewritten.
Finally, low internal quality is not directly manifested in external quality. At first it is evident in small schedule slips or small bugs. By the time low internal quality effects the external quality, it is usually to late. Hence, organizations that wish to continually improve products must use processes that measure and immediately address internal quality such as Extreme Programming 2.
Conclusion
Many organizations define product quality by how many bugs are found by a QA group. While good QA is essential to product quality, it is only one part of a marketing, business development and engineering effort.
Correcting quality problems is not simply fixing bugs. Product features must be carefully selected to address the needs of the target market.
Bugs and schedule slips may be symptoms of festering low internal quality. If these quality issues are not immediately addressed, the quality problems can eventually overwhelm any development efforts.
Carmine Mangione has been teaching Agile Methodologies and Extreme Programming (XP) to Fortune 500 companies for the past two years. He has developed materials to show teams how to move from standard methodologies and non-object oriented programming to Extreme Programming and Object Oriented Analysis and Programming. He is currently CTO of X-Spaces, Inc. where he has created an XP team and delivered a peer-to-peer based communications infrastructure. Mangione is also a professor at Seattle University, where he teaches graduate-level courses in Relational Databases, Object Oriented Design, UI Design, Parallel and Distributed Computing, and Advanced Java Programming. He holds a B.S. in Aerospace Engineering from Cal Poly Institute and earned his M.S. in Computer Science from UC Irvine.
Bibliography
1. “Designing User Interfaces”, Sato and Mullet
2. “Extreme Programming Explained”, Beck, K., Addison-Wesley Pub Co; 1st edition (October 5, 1999)