To do that we'll have to go back in time to
the late 60s. So what was happening in the 60s? Well for
example the first man landed on the moon. That was also
time when Woodstock took place and also the time when the first
60 second picture from Polaroid was created. Concurrently to these events,
which you probably didn't witness in first person, that was also the
time when people started to realize that they were not able
to build the software they needed. This happened for several reasons and
resulted in what we call the software crisis. So let's
look at some of the most important reasons behind this
crisis. The first cause was the rising demand for software.
Now you're used to see software everywhere: in your phone,
in your car, even your washing machine. Before the 60s,
however, the size and complexity of software was very limited
and hardware components were really dominating the scene. Then things
started to change and software started to be increasingly prevalent.
So we move from a situation where everything was mostly
hardware to a situation in which software became more and more
important. To give an example, I'm going to show you the growth
in the software demand at NASA along those years. And in
particular, from the 1950s to more or less 2000. And this
is just a qualitative plot but that's more or less the
ways things went. So the demand for software in NASA grow
exponentially. And the same happened in a lot of other companies.
For example, just to cite one, for Boeing. So the
amount of software on airplanes became larger and larger. The
second cause for the software crisis was the increasing amount
of development effort needed due to the increase of product complexity.
Unfortunately, software complexity does not increase linearly with size. It
is not the same thing to write software for a
class exercise or a small project, or a temp project,
than it is to build a software for a word processor,
an operating system, a distributed system, or even more complex and larger
system. And what I'm giving here is just an indicative size for
the software so the class exercise might be 100 lines of code,
the small project might be 1000 lines of code, in the other thousand
lines of code, and so on and so forth. For the former,
the heroic effort of an individual developer can get the job done.
So that's what we call a programming effort. If you're a good
programmer, you can go sit down and do it, right. For the latter,
this is not possible. This is what we called the
software engineering effort. In fact, no matter how much programming languages,
development environments, and software tools improve, developers could not keep
up with increasing software size and complexity. Which leads us to
the third problem that I want to mention and the
third reason for the software crisis. And this cause is the
slow developer's productivity growth. So let me show this again
with a qualitative diagram. And this is taken from the IEEE
Software Magazine. And what I'm showing here is the growth in
software size and complexity over time, and how the developers' productivity
really couldn't keep up with this additional software complexity, which resulted
in this gap between what was needed and what was actually available.