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