The benefits of code quality

Wednesday Sep 1st 1999 by Linda G. Hayes

Emerging technologies assist in quantifying and managing code construction and its affect on an application's quality. But they're only part of the solution.

If beauty is in the eye of the beholder, where does quality fit in? There are undoubtedly aspects of quality in how an application appears and behaves, but what about what you don’t see? What about the quality of construction?

Software applications may be appealing and powerful on the outside but overly complex and fragile underneath. For example, code that does not follow naming or documentation conventions, is excessively interdependent or complex, or is simply poorly structured can cause minor changes to have a major--and too often unexpected--impact.

An entire discipline of software quality revolves around the way the code itself is constructed and how it affects the quality of the application. In fact, some argue that more defects can be removed through thorough code inspections--static review of the code by others--than through code-level testing--which involves execution by the development author.

Once you lose control of your code, it’s almost impossible to get it back without rewriting it.
Not surprisingly, emerging technologies are available to assist in quantifying and managing this aspect of development and testing. From a software testing perspective, these technologies have merit. While such products are not 100% of the solution--you still need system testing--they are an important component.

A competitive advantage

Peter Sliwkowski, vice president of core product development and product management for applications tools vendor Progress Software Corp., in Bedford, Mass., has implemented one of these new products with interesting results and advice. Sliwkowski is responsible for a Progress product unit with a $250 million annual budget, which encompasses 150 professionals and about six million lines of code across all of the products.

About a year ago, his area acquired well over one million lines of source code from a third party and needed to understand how to move forward with enhancements and modifications. Concurrently, Progress’ Y2K remediation effort was underway and Sliwkowski needed a roadmap to guide the developers through the process of identifying and remediating any problem code, then testing the changes for accuracy and completeness. He chose Burlington, Mass.-based Software Emancipation Technology Inc.’s DISCOVER product set, which is a complete solution for managing large, complex software development projects composed of C and C++ code.

Wrestling with requirements
In a nutshell, DISCOVER inserts itself into the compile/link process to gather information about how the code is constructed and whether it conforms to best practices and rules in such areas as programming constructs, portability, globalization, and structure. These results can be summarized into a high-level, quantitative measure of overall software quality and weighted according to customer-specific importance.

"The Quality Analysis Report (QAR) helps us get a better handle on providing a sense of the implicit quality of our product,” says Sliwkowski. “We believe DISCOVER gives Progress a competitive advantage by finding issues before we ship."

Pay now, save later

While quality code adds value to your first shipment, it’s even more important for managing subsequent releases and updates. One of the most challenging facets of software development is actually the maintenance. How do you make changes in a system that has complex interrelationships you may not even be aware of? For instance, when one of many developers working on a system creates or changes a component, such as a database table, that affects other developers’ modules without their knowledge. This problem is compounded if you acquired the source from someone else or even from another company, which may have its own development environment, approach, and conventions.

I am aware of at least one financial application for a major oil company that became so enormous and entangled after the original developers left that the company decided to cease any and all changes to the code. Instead, external workarounds were written to avoid potentially disturbing the code’s incomprehensible logic. Once you lose control of your code, it’s almost impossible to get it back without rewriting it.

At Progress, Sliwkowski concluded that DISCOVER helped get new engineers up to speed on the company’s architecture more quickly by revealing the impact of architectural changes, providing decision support capabilities for software engineers, and finding system quality issues before shipment.

Test here, not there

Because we all know from painful experience that changes can have unanticipated results, most test efforts are designed to cover as much of the system as possible. While this is an admirable and sensible goal, time and resources may not always permit it.

Some say more defects can be removed through thorough code inspections--static review of the code by others, than through code-level testing--which involves execution by the development author.
To make this process more efficient, DISCOVER, for instance, provides a tool called TestLink, which is designed to identify which areas of the system are affected so that only those specific tests need to be performed, thus optimizing testing time.

Although any tools that can help focus test efforts for developers can be useful, in my experience they should not be applied to system and regression testing for the simple reason that these phases are important for flushing out issues that cannot be known from the code itself. For example, changes that should have been made but weren’t, unpredictable interactions with other interfaces, or missed or incomplete requirements.

Culture shock

Like all IT tools, DISCOVER and other products like it, such as McCabe IQ from Columbia, Md.-based McCabe & Associates Inc., require a commitment to a cultural change. It must be integrated into the company’s software development processes and adopted by the engineers. If it is not used, or not used properly, you won’t see the benefits. These tools are even more difficult than most to adopt, because they directly affect the very heart of what developers do--write code--and there are inherent and deep-seated habits both within companies and individuals about how to build and maintain software.

This means that regardless of the power or promise of the technology, there is no substitute for solid strategies and training for using it. So, don’t expect this or any other tool to introduce code quality. Expect it to give you the means and the measurements to manage and improve your development process.

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved