On building software process models under the lamppost
ICSE '87 Proceedings of the 9th international conference on Software Engineering
A software process immaturity model
ACM SIGSOFT Software Engineering Notes
High-pressure steam engines and computer software
ICSE '92 Proceedings of the 14th international conference on Software engineering
End-to-end arguments in system design
ACM Transactions on Computer Systems (TOCS)
Software aspects of strategic defense systems
ACM SIGSOFT Software Engineering Notes
Are We Developers Liars or Just Fools?
IEEE Software
HOTOS '01 Proceedings of the Eighth Workshop on Hot Topics in Operating Systems
Addressing reality: an architectural response to real-world demands on the evolving Internet
FDNA '03 Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture
Communications of the ACM - Transforming China
ACM SIGSOFT Software Engineering Notes
A critical programmer searches for professionalism
ACM SIGSOFT Software Engineering Notes
ACM SIGSOFT Software Engineering Notes
Emergent (mis)behavior vs. complex software systems
Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006
The Grand Theory of Everything: what man-made systems are, and why they fail
ACM SIGSOFT Software Engineering Notes
Communications of the ACM
A systems analysis of systems integration
ACM SIGSOFT Software Engineering Notes
Debugging debugged, a metaphysical manifesto of systems integration
ACM SIGSOFT Software Engineering Notes
In search of dependable design
Communications of the ACM - Web science
Image Crisis: Inspiring a new generation of computer scientists
Communications of the ACM - Web science
Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses
SP '08 Proceedings of the 2008 IEEE Symposium on Security and Privacy
IEEE Software
IEEE Spectrum
The epistemology of computer security
ACM SIGSOFT Software Engineering Notes
The limits of systems-making organizations
ACM SIGSOFT Software Engineering Notes
Hi-index | 0.01 |
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..