Can High Quality Software Be Useless?

I have been thinking quite a lot about software quality recently. We are in the midst of delivering a project that has some deadline pressure, making me wonder about whether I should trade off certain aspects of quality to get to market quicker. The classic dilemma.

I think there is a danger however, when thinking about software quality, to just think of the code itself: nicely abstracted, easy to change, well tested. However, if we are too narrow in that view, it means you could have the highest quality software in the world that is functionally useless. Value to customers must make up part of our quality assessment.

By some means of deus ex machina while I was wrestling with this quandy I came across this paper: How Developers and Managers Define and Trade Productivity for Quality. Here is the abstract:

In this paper, we present the findings from a survey study to investigate how developers and managers define and trade-off developer productivity and software quality (two related lenses into software development). We found that developers and managers, as cohorts, are not well aligned in their views of what it means to be productive (developers think of productivity in terms of activity, while more managers think of productivity in terms of performance). We also found that developers are not accurate at predicting their managers' views of productivity. In terms of quality, we found that individual developers and managers have quite varied views of what quality means to them, but as cohorts they are closely aligned in their different views, with the majority in both groups defining quality in terms of robustness. Over half of the developers and managers reported that quality can be traded for higher productivity and why this trade-off can be justified, while one third consider quality as a necessary part of productivity that cannot be traded. We also present a new descriptive framework for quality, TRUCE, that we synthesize from the survey responses. We call for more discussion between developers and managers about what they each consider as important software quality attributes, and to have open debate about how software quality relates to developer productivity and what trade-offs should or should not be made.

Overall, a really interesting paper for a number of reasons, but I highlight it for the TRUCE framework of quality they propose:

T: Timely and predictable delivery of features

R: Robustness of code (reliable, tested, secure, scales, etc.)

U: Meets user, customer, stakeholder requirements/needs

C: Readable, documented code to facilitate collaboration

E: Evolvable design with tests to support future changes

I really like this framework as I think it captures a more holistic picture of software quality that doesn’t just focus in on the code itself.

Can high quality software be useless? Yes, but it depends on how you are measuring quality. Ensure your quality criteria makes it impossible.