We will start our discussion about test written and development by going
back to a softer life cycle to examine a little bit ago
which is the waterfall life cycle. And if you remember, that was
a totally rigid process in which we were preparing documents and we
were not studying any phase before the previous one was finished. And
once a phase was finished, we were really going back to it.
So today we are going to examine how it is possible to go
from such a rigid process to an agile one, in which we can
better deal with changes. So remember what we saw in the
first lesson when Barry Boehm stated that the cost of change
grows exponentially with time. So if we imagine to have time
over here on the x-axis and cost on the y-axis, we
can see the cost that will go up more or less
this way. And what that means is finding a problem while
collecting requirements will cost you much less than finding a problem
in the analysis phase, which in turn, will cost you less
than finding a problem during design, and so on for
the subsequent phases. So if this is the case, and cost
is really growing this fast as we proceed in our process,
what should we do? The key thing is to discover errors
early before they become expensive, which in turn means doing a
lot of upfront planning. And because models are cheaper to modify
in code, we're willing to make large investments in upfront analysis
and design models. And only after we have built and checked
these models, we're going to go ahead and build the code. In
other words, we are following
a waterfall mentality. However, something definitely
changed in the last 30 years. For example, 30 years ago,
we needed to walk down the hall, submit a deck of
cards to an operator, and wait a day for our program
to run and produce some results. Today we can leverage the
computational power of the cloud. Computers used to be very slow
and very expensive. Today, computer are a thousand times faster and
a thousand times cheaper than what they used to be. In
particular, if you think about the compile and test cycle, that has
gone from days to seconds. Now we can change our code, compile
it, run it our tests, all in a matter of instants, something
that was unthinkable before. Finally, developers in the past had to
do a lot of tasks manually in a very time-consuming way and
often in a very painful way. Today, on the contrary, we can
now automate a lot of these tasks. We have high level programming
languages, version control systems, smart ideas. Basically a whole set of tools
that can help developers. And they can make them more efficient. In
general, what that means is, it's easy to change, much easier than
what it was before. So maybe if we take all that into account,
the cost of change can be flat. So if we go back
to our diagram, the one in which we showed the cost with
respect to the project time, maybe instead of having this kind of
curve, we might have a different kind of curve. Maybe the curve is
more like this one. So maybe we can make all of this happen, as long as
we use tools, practices and principles in the
right way. And we're going to see what that means.