Software Crisis

There is a lot of excellent software development being done by programmers, and there are a lot of unhappy users who can't find software that works the way they think it should. But as somebody said a decade or so ago, it's not a crisis because it's been going on too long. Every now and then, someone comes up with a cure, but it usually results in programmers being able to do bigger and better software that does things that the users don't want, or fails to do what they do need.

It is arguably a complexity crisis rather than a software crisis. Software gets blamed because software is our best tool for handling complexity.

I mumbled something about this on EntropicLawOfComplexity. It was later munged, but I think there may be something still there worth reading.

XP includes some techniques designed to fix some of the problems that lead to the idea that there was/is a SoftwareCrisis. Like: get something that user asked for running and back to the user fast. Like: get two brains working on a piece of code. Like: test test test test. Like: Don't re-organize when you add something new, instead add the new thing, test it, then reorganize, then test...

I believe the term was coined by DougMcIlroy, while presenting his paper on mass produced software components to the NATO Conference in Software Engineering conference in 1968. The crisis turned around the management of three dimensions:

• number of programmers
• complexity of the applications (demand)
• productivity (plagued by the mass of existing software)

-- MarcGirod

Particularly in the context of in-house information systems, I blame stovepipe applications and a lack of reusable information system services. Try DoItFramework for a suggested cure. -- JimRussell