Real Developers Demand Application Quality Measures
Dr. Bill Curtis is the Senior Vice President & Chief Scientist of CAST Software
The Misperception that Developers Dislike Quality Data
For decades, IT executives wanted to use software quality data as a basis for evaluating the performance of their developers. When implemented, this worst practice led to anger, mistrust, and untended side effects. Clever developers learned how to maximize their numbers at the expense of other important outcomes. Because developers are proud of their professional work, because many managers are not current in development technology, and because software is a nascent engineering discipline, developers react quickly when they sense the misuse or misinterpretation of quality data. These reactions cause many to believe that developers abhor measures on the quality of their work.
Not true! When used for improvement and self-management rather than performance evaluation, developers have embraced quality data with profound benefits. Many developers use static code analyzers on their components as part of their unit testing. Watts Humphrey has demonstrated through use of the Personal Software Process that developers can use their own data to make extraordinary improvements in their personal performance. The key to using quality data effectively is in understanding why developers need such data and how it can empower them.
Why Application Quality Data Is More Important Than Ever to Developers
Application developers have always sought insight into the architectural and engineering attributes of their applications. These attributes can be measured and displayed in a form that provides developers with profound knowledge about the maintainability, robustness, security, usability, performance, and other aspects of their applications. These measures have been available since the late 1970s, but only recently have emerging trends motivated their adoption in leading IT organizations.
Over the last decade, four dramatic transformations in application development have elevated the importance of measures characterizing the internal quality of software. Unfortunately, these trends have made such data far more difficult to collect manually.
- First, applications are no longer monolithic heaps of code written in a single language. Rather, they are developed in multiple tiers, each with a different system function, performed by a different technology, written in a different language. Consequently developers can no longer be expert in all the technologies being integrated into an application. They need insight into how their components will interact with technologies in other tiers.
- Second, applications are now developed by multiple teams often on multiple continents who may be employed by different companies. In highly distributed environments, informal channels of communication are no longer adequate for exchanging critical technical information between teams. Tacit knowledge about the application must be supplemented with current and objective facts about the application and its attributes.
- Third, many of an applications most critical weaknesses are difficult to detect through testing. Testing typically focuses on functional defects. The most devastating defects in operation are frequently non-functional defects for which test cases are difficult to devise. Even stress and load testing often fail to adequately simulate operational conditions, leaving critical problems undetected. Development teams need much more comprehensive information about the quality and integrity of an applications architecture, coding, and component interactions across technologies and tiers.
- Fourth, developers are beginning to see their role from a different perspective. They are moving beyond the antiquated role of an isolated craftsman, to embrace the more encompassing role of providing a service to the business. This transformation has been accelerated by the agile movement. To ensure they are providing the best service possible, developers need current and objective information on the architecture and quality attributes of the application that delivers the service.
As IT applications perform an increasing proportion of an enterprises critical business functions, as their development becomes more complex, and as developers accept greater responsibility for how well their software serves the business, developers become more receptive, and often even eager for greater insight into problems that degrade the effectiveness of their applications.