Systems of all natures affect the outcomes of all engineering projects, but software engineers working with business systems must consider and anticipate the interactions of non-technical systems to a greater degree. Studies of software project failure have not indicated widespread technical deficiencies among practitioners, but instead issues related to understanding requirements, trust in solutions, and how they are rolled out. A software system typically exists within an environment of other systems each affecting the operation of one another in seemingly unpredictable manners. These systems can include other information systems, institutional or political systems, and social systems. Consequently, software professionals often require a level of appreciation for systems that go beyond their technical scope to ensure the success of their projects. The socio-technical nature of software systems has not been lost on the field; however, software engineers can always benefit from greater sensitivity to the nature of systems themselves.

Enter Systemantics, the 1975 book by John Gall which earned Gall a law of his own: Gall’s Law. An entertaining read, it also provides important insight for information professionals. The tongue-in-cheek style of Systemantics communicates concepts that are difficult to communicate save for personal experience, but certainly provides the practitioner with an important viewpoint if taken with a dash of salt. To this end, this article takes three major concepts from Systemantics and applies them to software engineering with the hope that it will enlighten practitioners on the travails of working with systems in a systems-dependent field.

Software is often deployed in environments where its success is immediately challenged by forces from non-technical systems. Not only do systems themselves, information or otherwise, pick up inertial forces causing an inherent resistance to change, but there is also the phenomenon of software systems being used as a primary means to effect change upon neighbouring systems. The former being a passive response and the latter an opposing response to an active force, both of these situations result in external forces exerted upon the software system. Gall’s advice for anticipating opposing forces is termed the Systems Law of Gravity which states that “Systems Run Best When Designed to Run Downhill” (p. 102).

When a software system is used as a primary force to impose change on neighbouring systems, an opposing force of some degree is almost a certainty. This is not to say that software cannot be a tool in a broader program to effect change, but expecting to make institutional change solely by using one system to affect another is unpredictable. For example, software systems are often used to enforce policies and procedures: A CRM to strongarm a sales process, an expense reporting system to enforce a high level of rigidity, and checklists in Electronic Health Records (EHR) to require doctors to ask a regiment of questions. And yet, each of these is naturally resisted by the social systems in which they interact. Denton writes of doctors needing to meaninglessly check through lists containing questions of “exercise-induced chest pain and feelings of anxiety” for a two-month old. The burden of a poorly configured CRM is also well documented. Peter Drucker commented that, “our civilization suffers from a superstitious belief in the magical effect of printed forms.” If the sales process is not already enforced, the expense report procedures not taken seriously, and the medical checklists not already agreed upon, then software will fail to enforce any of these. Even a system that happens to work today at tightly controlling a process might become too rigid in the future. As Gall also states, “Loose Systems Last Longer and Function Better” (p. 103).

Inertial forces are troublesome as they lie dormant out of the control of the engineer. As Gall states in the Law of Systems-Inertia, “A system that performs a certain function or operates in a certain way will continue to operate in that way regardless of the need or of changed conditions” (p. 86). For example, staff may be loathe to retrain, key users may be too busy to use the system to keep necessary data up-to-date, or staff may resent having lost control of their spreadsheet to an application from the IT department. Running downhill in this case often means simply being aware of the non-technical workings of an organization, and then designing the technical system to work with these tendencies (and human nature), and not against them. Integrating a new system within an existing one, or providing interim measures to keep control in the hands of the staff are both examples of running downhill with non-technical inertial forces.

Many of Gall’s axioms can be seen in a number of the best practices that have evolved in software engineering. Working in smaller iterations with continuous user feedback mitigates the possible unexpected outcomes of introducing a new software system. Indeed, this approach enables software professionals to contribute new solutions while continually monitoring any unintended consequences in a controlled manner. Moreover, by working alongside the sources of potential opposing forces, inertial forces are further mitigated allowing the software to effectively “run downhill.”

The third point (“Do it without a system if you can”) offers a further conclusion that is often understated: make sure that the problem being solved is actually a software problem. The purpose of this article is not to set a hard-and-fast rule for determining what is a software problem; however, from the example above, creating a digital employee punch-in/punch-out system because pen-and-paper has become cumbersome is a much stronger case for software than creating the same system because supervisors are disinterested in staff behaviour. If there are steps missing between the problem statement and the recommendation of implementing a software system, then other options may need to be evaluated.

Finally, a common theme among all of this is the importance of having management involved in the development and deployment of software systems. Sharing concepts with W. Edwards Deming’s The New Economics, management’s job is clearly stated as “to direct the efforts of all components toward the aim of the system,” where the aim is ultimately to “achieve the best results for everybody” (p. 50). Software systems are components of the greater business therefore requiring management to ensure that advancement in software components translates to advancement for the business as a whole. This is especially true where it is necessary to make larger scale changes to business systems, or where a business problem must be solved immediately with a software solution. “Growth in size and complexity of a system […] require overall management of efforts or components” (p. 53). As discussed, in a software system these efforts and components are never only technical in nature.