The first law of software engineering is that there are no laws of software engineering, at least, yet! As the recently deceased software engineering pioneer Watt S. Humphrey had so succinctly said, “Physicists and engineers make approximations to simplify their work. These approximations are based on known physical laws and verified engineering principles. The software engineer has no Kirchoff’s law or Ohm’s law and no grand concepts like Newtonian mechanics or the theory of relativity”.
Where would the laws of software – when we do discover them – be placed in the pantheon of factors that influence software development? Booch has identified the following levels in the limits of software: influence of politics, impact of economics, importance of organizations, problems of functionality, problems of design, difficulty of distribution, challenges of algorithms, laws of software, and laws of physics.
When we compare the state of the art in software engineering, vis-à-vis other engineering disciplines the following lines of divergence can be noted:
Predictable outcomes – Engineers are focused on ensuring there is lowest possible surprise in the production process so that its outcome can be accurately predicted. On the other hand, software engineers reared in the art of programming and/or computer science research often regard surprises and unpredictability of outcome as key motivators for software development.
Design metrics – Software engineers do not have corresponding metrics for allowable stresses, tolerances, performance ranges, structural complexity, failure probabilities, etc. These are routinely used in other engineering disciplines. Commonly used retrospective measures of software, such as lines of code or performance ranges, may present an oversimplified view of the problem domain.
Failure tolerance – The fundamental aim of any engineering effort is to prevent failure; and when it unfortunately occurs, to learn from it. Software systems fail often and sometimes spectacularly. Yet software engineers do not have an established framework to document and share the lessons from such failures.
Separation of design from implementation – In other engineering disciplines, designers design and handover the ‘blueprints’ to the construction specialists. Software design and implementation together are too closely tied conceptually to enable such a separation. The same software engineer usually has to do both, often simultaneously.
It is wondrous and a little confusing how software engineers manage to create systems of such complexity and criticality in spite of such divergences and without an established set of basic ideas and first principles (enshrined as laws) to fall back upon.
But then, wondrous yes, but confusing, may be not, as structures of immense grandeur and longevity have been built when humans had no inkling of the laws that underpinned such feats of engineering. The pyramids of Egypt are just one example.