Empirical software engineering models: Can they become the equivalent of physical laws in traditional engineering?

Traditional engineering disciplines such as mechanical and electrical engineering are guided by physical laws. They provide the constraints for acceptable engineering solutions by enforcing regularity and thereby limiting complexity. Violations of physical laws can be experienced instantly in the lab. Software engineering is not constrained by physical laws. Consequently, we often create software artifacts which are too complex to be understood,tested or maintained. As too complex software solutions may even work initially, we are tempted to believe that no laws apply. We only learn about the violation of some form of "cognitive laws" late during development or during maintenance, when too high complexity inflicts follow-up defects or increases maintenance costs. Initial work by Barry Boehm (e.g., CoCoMo) aimed at predicting and controlling software project costs based on estimated software size. Through innovative life cycle process models (e.g., Spiral model) Barry Boehm also provided the basis for incremental risk evaluation and adjustment of such predictions. The proposal in this paper is to work towards a scientific basis for software engineering by capturing more such time-lagging dependencies among software artifacts in the form of empirical models and thereby making developers aware of so-called "cognitive laws" that must be adhered to. This paper attempts to answer the questions why we need software engineering laws and how they could look like, how we have to organize our discipline in order to build up software engineering laws, what such laws already exist and how we could develop further laws, how such laws could contribute to the maturing of science and engineering of software in the future, and what the remaining challenges are for teaching, research, and practice in the future.