Software crisis

The software crisis was a term used in the early days of software engineering, before it was a well-established subject. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems which could be tackled. In essence, it refers to the difficulty of writing correct, understandable, and verifiable computer programs. The roots of the software crisis are complexity, expectations, and change.

Conflicting requirements have always hindered the software development process. For example, while users demand a large number of features, customers generally want to minimise the amount they must pay for the software and the time required for its development.

The term software crisis was coined by F. L. Bauer at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. An early use of the term is in Edsger Dijkstra's 1972 ACM Turing Award Lecture, "The Humble Programmer" (EWD340), published in the "Communications of the ACM". Dijkstra states:

The causes of the software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession. The crisis manifested itself in several ways:
* Projects running over-budget.
* Projects running over-time.
* Software was of low quality.
* Software often did not meet requirements.
* Projects were unmanageable and code difficult to maintain.

Various processes and methodologies have been developed over the last few decades to "tame" the software crisis, with varying degrees of success. However, it is widely agreed that there is no "silver bullet" ― that is, no single approach which will prevent project overruns and failures in all cases. In general, software projects which are large, complicated, poorly-specified, and involve unfamiliar aspects, are still particularly vulnerable to large, unanticipated problems.

See also

* AI winterThe myths in Software crisis can be classified to three namely:

Managerial MythsCustomer Myths Practitioner Myths

Managerial Myths----There is a ready set procedure for production of software.Hardware that is necessary to the process is essential. Once the process takes too long, we can always get new programmers.

Customer Myths

Only the general set of objectives are essential, other details can be filled later.Believe that change cannot affect the usability of a program because programs are dynamic.

Practitioner Myths

The quality of a program can only be determined when it's up and running.Once the program is running, there is no other business on the side.The only success is a running program.

References

* [http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html Report about the NATO Software Engineering Conference dealing with the software crisis]
* Edsger Dijkstra, [http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF "The Humble Programmer"] (PDF, 473KB).