Can we engineer enterprise software as machines?

Software components, unlike the particulars found in nature, are not constrained by natural laws. That natural constraint, the lower-level principle that intrinsically limits the complexity and interdependency of design constituents, is what the design, the higher-level principle, relies on. The lack of those natural constraints and physical dimensions in software implies that solutions that make tangible material meet our expectations do not apply. It means that writing software as a design activity is fundamentally different from the design activity in conventional fields of engineering. Engineering activity is how engineers decipher problems within the set of constraints imposed by the medium in which they are working. Construction isn’t software because it is constrained by the mechanical properties of the materials. Electronics isn’t software because it is constrained by the electrical properties of the components. Mechanical engineering isn’t software. Chemical engineering isn’t software; medical practice isn’t software, etc., etc.

Because software, not being made of matter, has no law of inanimate nature to be harnessed by the principle of design, software engineers, trained with knowledge of design (e.g. information engineering), do not have the scientific knowledge that design knowledge relies on. As such, software engineers design “bridges” without the knowledge of “material mechanics.” Accordingly, what we have is an enterprise software system whose principle of design, which supplies the defining functions, has no foundation to rely on. Either that, or the understanding of this foundation is not made deliberately explicit and remains in the background. As a result, solutions created by using the higher principle only work for conventional engineering, and do not work for software. Because of the lack of lower constraint in software, there is no tangible solution equivalent to conventional engineering in software. Accordingly the working of software tends to be arbitrary rather than anticipated by the theory.

Because of lack of complexity limiting natural constraints, if left otherwise unchecked, software will tend to expand arbitrarily, towards the only constraint left—the capacity of our brains. Arbitrary personal opinions, instead of practices guided by theory (such as the theory of harnessing lower-level principles), are what condition the outcome of software. This lack of objectivity (and accordingly, excess of arbitrary subjectivity) in software design activity is the central reason for practice and theory decoupling in software engineering. This lack of objectivity raises people’s expectations beyond all reason of what can and should be achieved within the project’s time and resource limitations. Given the fact that people are inconsistent in general, the practice of software engineering is more guesswork than disciplined inquiry. The desire to emulate engineering design to software is logically flawed and is the root cause of theory and practice decoupling in today’s software engineering.

Because all machines operate under the control of two distinct principles and if we want to design an operable machine, we must be explicit in our design on both level principles and how the higher-level principle harnesses the lower one. We should never, in principle, fail any traditional engineering design, whether it is a bridge, a vehicle or a building because we can in theory identify particulars at the lower level and construct higher level principle that harnesses the lower particulars precisely to fulfill defined functions. While today’s software systems are designed under one principle, the principle of design, without knowledge of lower level particulars and their governing laws. Therefore, we are confident to say that the lack of lower principle in software design makes software systems not operable. This insight points us a way forward to resolving the failure of software engineering, that is to construct and include lower principle into software. What is the lower level principle and what knowledge is required to construct such principle in enterprise software?