Software Quality

I’ve been fascinated for years by the question:

For each domain X, what is good software and how do the people working in domain X produce it?

So far, I’ve sought answers to question in texts, conversations, reflection, and experiments.

Texts and Conversations

The readings and conversations that have been most helpful to me so far have been:

• Fred Brooks’ “The Mythical Man Month”
• Charles Fishman’s “They Write the Right Stuff”
• Daniel J. Bernstein’s “Some thoughts on security after 10 years of qmail 1.0”
• conversations with Dave Kasik and John Chilenski on DO-178B, the MC/DC criterion, and Boeing’s approach to software quality assurance in life-critical airborne systems.
• DOD-5200.28-STD: Trusted Computer System Evaluation Criteria
• Nancy Leveson’s “Engineering a Safer World”
• Atul Gawande’s “The Checklist Manifest”

Reflections

My thoughts on how to analyze projects for quality are:

1. Start from the assumption that the quality of the products of a software endeavor are determined by the quality of the means, the situation, and the cognitive approach of the endeavorers.

2. Adaptively search for “material remains” bearing the imprint of significant thoughts, words, actions, habits, and environmental conditions. “Material” remains are artifacts which exhibit a surfeit or a dearth of any of the following qualities:

awareness:	are people deeply aware of their decisions’ consequences?
justification:	are the results of the decision defensible?
economy:	are things as simple as possible but no simpler?
craft:	is the work good?
coherence:	does the decision harmonize with previous decisions?

Experiments

I have not yet performed any experiments whose results were definitive.

tbd.

Explain control, technical debt, OQE, and the “production” vs. “research” distinction.