Assumed Goodness

Yesterday was 25 years since the Challenger disaster. A NASA engineer from that time attributed the accident to carelessness and ‘assumed goodness’. When the Shuttle program seemed to be going well the engineers let down their guard and began to assume that everything would work properly unless there was evidence to the contrary. Of course with an endeavour as dangerous as space flight it is necessary to assume that nothing will work properly unless there is evidence to the contrary. The loss of the Columbia seventeen years later showed that the attitude of assumed goodness recurs unless intentionally and constantly avoided.

While most software design is not fraught with the danger of space flight, the tendency toward assumed goodness is the same. Software fails because the designer (or the end user – but I’ll get to that later) creates an incomplete specification that assumes implementation in a logical, intuitive manner. If the programmer does not share the vision of the designer the result may be neither logical not intuitive, resulting in a program that is inefficient and frustrating to use.

The only solution I can think of is a lot of work trying to help the entire design/programming team to share the vision. Note that a shared vision is quite different from groupthink, which is a superficial appearance of agreement. I fear that a truly shared vision may only appear in the product it creates.