The Software Crisis
Resources
Video Script
The early days of computer science, in the 1950s and 1960s, were times of extreme growth and change in the field. In just a few short years, we went from ENIAC and UNIVAC, the first fully electronic and programmable computers, to commercial machines such as the PDP-1 that could be installed in offices and at universities for everyone to use. During that time, the creation of “software”, or programs that can run on these computers, became even more important than the creation of new hardware itself. At that time, one of the most notable computer scientists was Edsger Dijkstra, whose name you’ve probably seen before and will definitely see many times in this course.
In 1972, he gave a speech titled “The Humble Programmer,” wherein he described the situation in the world of software at that time:
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! … [N]ow we have gigantic computers, programming has become an equally gigantic problem -Edsger Dijkstra, The Humble Programmers (1972) Basically, as computers have become larger and more powerful, the task of creating equally large and powerful computer programs has also become gigantic, and the field struggled to keep up. This lead to a situation we refer to today as the “software crisis”
It’s really difficult to put into perspective how the world of software has changed over the years, but I’ve found that this graphic is a good place to start. This graphic examines the number of “lines of code” that are present in various pieces of software throughout the years. For example, the entire software program for the Apollo 11 spacecraft only requires around 145,000 lines of code. While that may seem like a large program compared to what you’ve written so far in your career, and it really is, it is miniscule in comparison to some later software. Moving ahead to more recent times, the Windows XP operating system, released in 2001, consists of an estimated 45 million lines of code! Imagine trying to look through all of that code to find the source of a bug or fix a security flaw - it could seem almost impossible.
So, as software programs have grown larger and larger, the issues that software development companies face have also become larger and larger. During the software crisis period in the 1960s and 1970s, many large scale software development projects failed. They ended up costing more money and taking more time to develop than was estimated, and the final product was often inefficient and low quality, if it was finished at all. Then, as hardware improved and programs needed to be updated, developers found it nearly impossible to go back and maintain their code since it was so difficult to follow in the first place. There are numerous reasons that could be cited as a partial cause of the software crisis, but one thing to keep in mind is that computer science and software engineering were both very new fields, and hadn’t had much time to grow, mature, and make mistakes. Compare this to the centuries of scientific developments that lead to the electric light bulb or the steam locomotive, and its no wonder that a profession which hardly existed at all some 20 years prior would have a few growing pains as it matured.
To put it bluntly, programming is hard.
Programming well is even harder. Fortunately, that’s what we’re going to focus on in this class - improving our programming skill by writing more programs, while also focusing on writing better code.
The field of software engineering has adopted many new practices over the years as “partial solutions” to the software crisis. These include the introduction of new and better programming languages, which better help developers express themselves fluently while avoiding simple errors. We also have access to much better development tools, including live debuggers and static code analysis tools that help us code quickly and with fewer errors and bugs. We can use code repository tools such as Git and GitHub to track our code, manage multiple versions, and easily make changes as bugs are found and fixed. We’ve also adopted standardizes coding styles, documentation standards, diagrams, and more, all to help us write code and design software that anyone can easily understand. Finally, we’ve adopted the use of automated testing to help make sure our code does what it should, and we’ve brought in some of the standard practices from other engineering disciplines to help us constantly improve and focus on the use of standard processes and methods to avoid errors. Unfortunately, none of these is really a “silver bullet” that solved the software crisis outright, but each one is a step in the right direction.
So, a major goal in this course is to instill these ideas and approaches into your regular programming practice. Our hope is to get you to follow these new practices daily throughout this course, and help you build some good programming habits that will serve you well in the future.
Unfortunately, there is mounting evidence that the software crisis really never went away. There are lots of examples of recent failures due to software problems. Probably the most memorable for us today is the botched rollout of the Healthcare.gov website in the mid 2010s, as well as the recent Meltdown and Spectre vulnerabilities found in the design of modern processors themselves. If you pay attention to technology news, you’ll hear about another major bug or vulnerability found in software almost every day. If you are interested in these, click the links in the textbook to learn more about them. So, as future programmers, it is up to you to really engage with these skills, learn them well, and integrate them into your regular programming habits so you can build better and more effective software.