Software maturity

Abstract

What does it mean for a profession to be considered mature? How valid is the claim that software faults may be excused due to the immaturity of the field? In giving that claim serious consideration, one might assume that there are stages to maturity, that maturity doesn't arrive in the world fully formed. If so, an understanding of maturity may be found from the viewing of the differences across various professions in terms of stages of maturity, perhaps signaled by how a profession detects and handles faults. The question thus becomes more refined, "Are software professionals more or less mature than their counterparts in respective fields in regards to the detection and handling of faults?" Which raises the previously begged but now follow-up question: "To whom should software professionals be compared?" The down-select for professions to choose for this comparison was straightforward. First, to disregard a comparison with the physical sciences as one could make a strong case that programming is nothing more than data and rules. Ones and zeros may represent any object, on, off, true, not true, apples, oranges, aelopiles and zeppelins, and that rules on objects are infinitely mutable, literally valid now and invalid one-half a tenth of a millisecond later. Software is distinctively arbitrary where the physical sciences are not (well, except perhaps for the quantum and the astro). In joining software with the soft sciences, the likeliest candidates for comparison were identified as the fields of economics and law . Economics at first glance appears to be a combination of mathematics and logic applied to finance, and law appears to be a combination of philosophy and logic applied to rules of conduct. There also appears a commonality with these particular soft sciences and software in the attributes of design. Professionals in the field of economics design models of the world in terms of money. Professionals in the field of law design models of the world in terms of behavioral control, and software professionals design models for any purpose in any terms that one may choose to take. Software may be used to model both economics and law, so why not compare software professionals to their counterparts in economics and law. On further investigation in development of this text, the rationale for this investigation hurt the premise, for if one considered that software is applied logic, then software has no reason to be considered an immature field. Logic and philosophy go back at least to the ancient Greeks, to Aristotle! If software is immature in the light of history, then what would that say about the maturity of logic and philosophy? (Hush, you cynics!) This author began to have severe doubts, that perhaps this whole line of investigation was naively misguided. Further investigation yielded additional insights, that although maturity may be an interesting topic in its own right, perhaps it wasn't key to understanding software faults, that perhaps instead, it was the art of design , design being a common feature across software, economics and law. With this new direction in mind, and then taking one step back for perspective, perhaps the common feature across the professions could be the design of design? And so this author meandered on, down paths less traveled and more shadowed (note the subtitle), observing and describing all of interest, and taking off yet again in directions oblique, the instinct of authorial self-restraint placed in competition with curiosity, all tugged and pulled and fretted at this author. The conflict of design choice reflected in an investigation of design choice! Oh, how self-similar! Deja vu all over again! The themes of this paper that continued beyond the initial investigation of maturity are as follows: A study of games versus competition in design. The limits of competition and the implications of these limits. A revisit of standing philosophical problems in computer science, in particular: Chess, Searle's Chinese Room and the Turing Test, studied as competitions. An exploration of the meta in design. Conclusions, which were in the first draft imagined to be most unlikely given the initial premise but in revision became necessary and unavoidable. .