The software crisis is a term used, since the 1960s, to describe the increasingly complex task of developing software on ever evolving systems whilst ensuring it runs as intended and expected. Dijkstra in his 1972 lecture “The humble programmer” used the term to assert that as computers develop technologically so does the complexity of the software development process. In contrast, Royce in his 1991 paper “Current Problems” describes the software crisis as the difficulty in providing systems that both meet customer requirements and work without problems. The software crisis seems to consist of a number of issues:

• Not meeting customer requirements
• Late delivery of project
• Running over budget
• Errors in functionality
• Lack of quality standards
• Applications that are difficult to use
• Code that is difficult to maintain
• Code that is difficult to enhance

The problem with software development is that there is no particular way of achieving something and the code itself is often unseen and exists only as an underlying component of a greater framework. It can be contrasted to a more traditional profession such as Plumbing. In the plumbing trade there are set ways of working, certain rules that govern why things work such as water pressures and certain kinds of products such as seals, copper tubing, o-rings etc. Plumbing work is often carried out by contractors who have been “registered” as professionals with recognised authorities such as CORGI. With this in mind, if a new cistern needs to be installed it is simply a matter of evaluating what is needed, obtaining the parts and fitting them together then testing that all legal and safety requirements are met. With software development in mind there are generally little universal ‘parts’ available or legal requirements that need to be met and the system builder does not generally need to be registered in any way. There is also a heavy reliance on the system builder generating an acceptable design based upon what the customer has asked them to do, a toilet is a toilet and the plumbing behind it doesn’t vary wildly but computer systems can vary immensely.

Back in the old days of the home microcomputer and in particular the Z80 processor there was only a handful of machine commands and a very small number of registers to manipulate values. Writing a program was a relatively simple task because the screen, keyboard and speaker were simply areas of memory that needed direct manipulation – everything was transparent and everything was accessible – the developer had a complete view of the system. The only downside was that code tended to be long. In contrast, modern coding systems can still be quite long but many additional layers such as dynamic libraries, wrappers, components and helpers all hide functionality and take the developer several levels away from the computer instruction set itself. This together with different processors such as the Pentium, the Xeon, the Duron, Centrino, etc mean that different optimisations can be made to the code. The developer therefore never gets to have a complete view of the system end to end.

Understanding user requirements is, in my opinion at least, the most important factor of software development and a number of software development methodologies are available including the Waterfall method (Royce), Iterative and Incremental methods, Spiral methods and Object-Oriented methods. Newer methodologies such as XP and RAD pay particular focus to user requirements.

In our group project there were discussions about which language to develop the system in. I preferred C# or Java as good object-oriented languages but the other team members preferred Visual Basic and this was the chosen language. Whilst it is understandable why this decision was made under the context of an academic project, in the real world it could potentially impact future developments as future increments of the project would likely throw away earlier code and restart in a more appropriate language.

Prototyping allows systems to be built and expanded upon ensuring that functionality is captured and operates at every increment. XP in particular takes this approach to software development which sets teams of programmers working on projects directly with customers to provide quick solutions to problems which are later refined. This brings the end user and the developer closer together for the duration of the development which can bring added benefits.

With long software development projects especially public ones that can last several years methods such as the Waterfall methodology can fall into trouble. This is because the requirements analysis and design is carried out early in the project and once only through the lifetime of the project. Moore’s Law has traditionally held the belief that computer systems double in processing power every 18 months to 2 years. A ten year development project can therefore see a very different target machine to that expected at the outset. In addition, the users of the system are likely to change during this time as people move on, retire or work on other things and developers are likely to change leading to different ways of working.

Object-Orientation, attributed to Abbot (1983) and Booch (1982) is a technique that allows a move to a more “parts” based method of software building as described in the earlier example of plumbing. Breaking down a problem into its constituent components and building objects that interact with each other and that can be re-used offers a clearer and more logical way of building systems. Multiple objects can then arranged together into a common framework that represents the functionality of the intended system. As part of our group project we aimed to do this with the card slot, beeper and audit log. Another increment would have seen objects for the keypad, the cash slot and the deposit draw. All of these objects would be organised in the main ‘ATMSystem’ file which describes how they interact to provide for a working ATM system. These objects could later be reused and told to interact differently to provide other systems such as an in-store card loyalty system.

Ensuring that code can be understood, maintained and enhanced once delivery is complete is another task and this is a field being looked at through the use of Refactoring, a topic supported by well known names such as William Opdyke and Martin Fowler. Fowler in particular describes re-factoring as software development for software sake, something which is often desirable but unbudgeted.

Brooks, in his 1987 paper “No Silver bullet” identifies four aspects of software development that he believes leads to the software crisis, that of complexity, conformity, changeability, and invisibility. Three aspects are discussed above but the idea of conformity is an additional idea that seems be added by Brooks. This is the idea that a software developer may have to conform to arbitrary methods such as code layouts, syntax use such as variable naming. Often these do not follow a particular ‘Standard’ but are created arbitrarily and evolve over time.

A fairly simple calculation would be a day of week calculation. There are many ways to address this problem including lookup tables, mathematical formulas, counting from a particular date (e.g. 1st Jan 1904) . The more complicated the formula becomes the more chance of problems or unexpected bugs creeping in and it is often impractical to test the formula against every possible combination because there are over 3,650 days in a ten year span alone. Then there is backward compatibility as the calendar as we know it only came into existence in 1752 and 1873 in Japan which shows that these calculates do not necessarily cross international boundaries.