A rational theory of system-making systems

Abstract

All current models of software development abstract away key interactions of the hosting organization, the results of which can be seen in practice with the common reoccurrence of large software intensive system project failures. Poor model matches with reality can be detected by anomaly, by paradox, and by poor results when approved process is properly applied. The current paradigm is that the software development process (and the more inclusive systems development process) must be abstracted away from the host organization, and that this abstraction must be treated as the whole of the model. This model began its life as a useful fiction to permit a cutting out of what for small projects were (at the time) secondorder factors to enable a more concentrated analysis on the principal factors. For the smaller software project, this model has, and continues to work quite well. But over the decades, as systems and systems makers have grown in size and complexity, this working fiction has outgrown its ability to model reality, and at the same time due to past success, has assumed the trappings of a truth; a law not to be questioned. Arguments to date on software process have been only about what variant methodology to apply and how strict one should be in applying methods, but never about the validity of the boundaries of the model. All efforts for improvement have been no more than continual tweaking of a bad model to see what happens. The paradigm for a better model begins with the realization that the larger the system maker and the larger the system, the greater the influence of the internally directed goals, the politics and the structures of the organization have on the design and implementation of the product. This paper attempts to reintroduce these externalities through a new model; the system-making system model. This model can be used to explain observations; predict outcomes; identify where current theory should no longer be treated as law and where current practice should no longer treated as optimal. The advantage of this model happens also to be its only drawback (sigh), that politics must be discussed.

A critical programmer searches for professionalism

“…Capacity based accountability makes an attempt to cut through limitations in moral and role accountability but runs into the same limitation that shows up in trust's attribute of persistence. Neither capacity based accountability nor trust explicitly addresses how hard one should try in the presence of obstacles, as in: How hard should the programmer continue to disagree with the manager [33]? When harm results, the question of how hard one should have tried has specific meaning in the legal perspective which is addressed in liability based accountability.…”

“…4. Natural hazards that come from the infinite pool of unspecified "shall not" behaviors which are the conceptual limit of the specification [33] as applied to an infinite context of behavior and use, under proper design care. No amount of design care can resolve this limit as the specification is a model acting in a model of the world, not the thing acting in the world.…”

“…Organizational scaling leads to greater specialized role accountability that in turn disconnects the professional from what it has been traditionally important to be professional about. The increasing narrowness of responsibility is called "deskilling" [33]. One of the traditional principles of professionalism that has been retained (to society's detriment) is that professionals should only address what is within their particular field of expertise, that it is unprofessional to comment on what one has been deskilled from.…”

“…[13] Software professionalism in this light appears to be a myth, a strategic fiction, that "[a]t the very least, allowing programmers to think that they were professionals would go a long way toward reducing turnover and maintaining the stability of the data-processing staff." [13] Having a tractable, compliant, workforce then, becomes the key to driving business success and software faults [33] (or, depending on your point of view, software success and business faults [16]). That it is easier to promote myths, to generate false consciousness than to address real issues, that the ongoing suppressed conflicts between industry's and society's means and ends, in what is seen as good for business can actually harm society, is the real issue.…”

“…In assigning work, the manager breaks work down into tasks that are fixed, procedural, and formalistic, and fixed meanings and formulaic reasoning produce significant misconceptions in new contexts (such as when faults are detected, objectives not reached, and budgets and schedules not met). The detection of faults in plans when plans do not match reality will not necessarily lead to their correction, for in large organizations there is a significant decoupling of cause and effect, and where there is disconnection between cause and effect, there is little measurable difference between effective and ineffective behavior [33]. Was the software fault due to organizational policy?…”