TABLE OF CONTENTS Since the birth of software engineering in the late 1960s/early 1970s, the tendency has been to solve problems by adding rules and building methodologies to cover every eventuality, in the hope that eventually all possible situations would be covered and perfect, bug-free software would materialise on time and within budget. Alternative approaches lead to meta-methodologies such as ISO 9000, which aren't software engineering methodologies in and of themselves but represent meta-methodologies with which a real methodology is meant to be created the bureaucrat's dream which allows the production of infinite amounts of paperwork and the illusion of progress without actually necessitating the production of an end product.
These juggernaut approaches to software engineering run into problems because the very term "software engineering" is itself something of a misnomer. The standard engineering processes operate within the immutable laws of nature, so that, for example, an electrical engineer designing a circuit is eventually constrained by the laws of physics, and more directly by the real physical and electrical limits of the devices with which they are working. Software engineering, on the other hand, has no such fixed framework within which to operate. Unlike the world of non-software-engineering, there are no laws of nature to serve as a ne plus ultra.
Limits on software beyond basic resource-usage constraints arise entirely from artificial design requirements that can be changed at the drop of a hat (see Section 4.5.1), so that the software equivalent of "natural laws" are the design requirements for the...
