Software engineering was proposed in 1968 due to the desire to apply the disciplined, systematic approach of industry engineering design to software. The outcome of the field of software engineering, however, does not resemble any other branches of engineering. In comparison of projects, it has been observed that

• almost any process can be made to work on some project,
• any process can manage to fail on some project,
• heavy processes can be successful, and
• light processes can be successful.

According to 2004's Chaos Report, the success rate for software projects was a mere 31% in 2003. The remaining 69% either failed or were severely challenged. Moreover, software errors cost the U.S. economy $59.5 billion annually, according to NIST (2003), and 80% of development costs go to identifying and correcting defects. In fact, few products (of any kind) other than software are shipped with such high levels of errors.

The software engineering model does not predict the high success rate of lightweight processes and the low success rate of heavyweight processes. Obviously, poor management is a non-methodological factor of the greatest significance, but even normalizing to account for that does not give meaningful predictions. The lack of prediction of practice by the software engineering model indicates that the theory of software engineering is decoupled from its practice.

All these indicate that there is something fundamentally wrong with software engineering. Software projects, unlike bridges that are on budget, on spec, and do not fall down, are hardly on budget, hardly on spec, and almost always fall down. Investment in tools, technologies, quality assurance, and different methodology schemes are not helpful in fundamentally changing the status quo. The paradigm of software design being a branch of engineering design is in question and may well be the root cause of the software engineering failure of the present day.