1
00:00:07,760 --> 00:00:09,920
After watching this video, you will be able to:

2
00:00:09,920 --> 00:00:12,160
describe problems with the Waterfall method

3
00:00:12,160 --> 00:00:14,240
and describe the typical relationship between

4
00:00:14,240 --> 00:00:16,960
software development and
operations prior to DevOps.

5
00:00:18,480 --> 00:00:23,040
It's important to understand what brought
us to DevOps in order to fully appreciate

6
00:00:23,040 --> 00:00:24,480
the problem that it solves.

7
00:00:25,680 --> 00:00:30,560
Architects would spend months and
months designing the system on paper,

8
00:00:30,560 --> 00:00:33,680
creating requirements documents,
creating design documents, and making

9
00:00:33,680 --> 00:00:36,960
high-level designs, low-level
designs, system level designs.

10
00:00:38,160 --> 00:00:41,200
Then finally we'd get to a development phase,

11
00:00:41,200 --> 00:00:45,520
where development worked for months and months on features
in an isolated development environment.

12
00:00:46,480 --> 00:00:49,680
As they developed the code, if
the designs were wrong it was

13
00:00:49,680 --> 00:00:51,840
very expensive to go back to the architects.

14
00:00:52,960 --> 00:00:56,240
Once we developed all the code,
we would get to a testing phase.

15
00:00:56,240 --> 00:00:57,840
We would test all the code at once.

16
00:00:57,840 --> 00:01:00,720
Testing would open defects and
send the code back to development

17
00:01:00,720 --> 00:01:03,120
until no more severity 1 or 2 defects were found.

18
00:01:04,320 --> 00:01:08,640
At some point, development would release
the code to operations for deployment.

19
00:01:08,640 --> 00:01:11,680
This release for deployment
would happen several months

20
00:01:11,680 --> 00:01:13,920
after the code was written,
maybe even a year later.

21
00:01:13,920 --> 00:01:15,520
Some of these projects took up to two years.

22
00:01:16,880 --> 00:01:21,040
Then the operations team would take
what seemed like forever to deploy it

23
00:01:21,040 --> 00:01:23,680
because they had no idea what
the developers had built.

24
00:01:24,240 --> 00:01:26,800
And the operations team kept
it running from that point on.

25
00:01:28,160 --> 00:01:31,200
We call this way of working the Waterfall method.

26
00:01:31,200 --> 00:01:33,760
With Waterfall, everything happens in phases.

27
00:01:34,400 --> 00:01:38,000
Requirements are gathered and a
requirements document is generated.

28
00:01:38,000 --> 00:01:39,840
Then that phase ends.

29
00:01:39,840 --> 00:01:42,800
The artifacts for that phase
flow down into the next one.

30
00:01:42,800 --> 00:01:47,840
In the next phase, we do all the design and the
design is documented in high-level designs,

31
00:01:47,840 --> 00:01:51,120
low-level designs, system-level
designs, and then that phase ends.

32
00:01:51,760 --> 00:01:56,160
Those artifacts get passed down to the
next phase and the coding begins where

33
00:01:56,160 --> 00:02:02,240
developers take the low-level design documents
and write the code that implements those designs.

34
00:02:02,240 --> 00:02:05,600
There are entrance and exit
criteria to each of the phases.

35
00:02:06,240 --> 00:02:08,640
So, all along, we're coding in isolation,

36
00:02:08,640 --> 00:02:12,320
we're not integrating my module
with the next person's module.

37
00:02:12,320 --> 00:02:16,080
Finally, you get to the integration phase
when all those modules come together.

38
00:02:16,640 --> 00:02:21,840
This is the first time we realize, we don’t know
whether all these pieces even work together.

39
00:02:22,400 --> 00:02:27,280
And then we move on to the testing phase, because
now we've got a system that people can test.

40
00:02:27,280 --> 00:02:31,120
And as they find bugs, they must
go swim back, up the waterfall,

41
00:02:31,120 --> 00:02:34,480
and open some bugs in the coding
phase and do some re-coding.

42
00:02:35,040 --> 00:02:38,080
Finally, after all the testing,
we deploy the software.

43
00:02:38,800 --> 00:02:41,120
It is called Waterfall
because if there is a problem,

44
00:02:41,120 --> 00:02:45,520
it is very hard to go back,
like trying to swim up a waterfall.

45
00:02:45,520 --> 00:02:48,240
You have to go all the way
back to the design phase.

46
00:02:48,240 --> 00:02:51,840
In fact, because we treat software
development like civil engineering projects,

47
00:02:51,840 --> 00:02:57,760
sometimes some of those architects
have moved on to the next project,

48
00:02:57,760 --> 00:03:01,040
and you've got to go find them and
then get them to change the design.

49
00:03:01,040 --> 00:03:04,400
You get the developers to change the code
and hope that it integrates this time.

50
00:03:04,400 --> 00:03:09,600
This process was very error prone and there was
no room for making changes late in the process.

51
00:03:09,600 --> 00:03:13,680
You didn't know whether it worked until
the end, so it was very high risk.

52
00:03:13,680 --> 00:03:16,320
But we developed software like this for years.

53
00:03:18,080 --> 00:03:22,480
What is wrong with this approach?
Well, there's no provision for change.

54
00:03:22,480 --> 00:03:24,960
Every phase has entrance and exit criteria.

55
00:03:24,960 --> 00:03:27,840
When one phase ends, the next one begins.

56
00:03:27,840 --> 00:03:31,120
There's just no provision for
going back and changing the design

57
00:03:31,120 --> 00:03:34,000
or changing the requirements
or anything like that.

58
00:03:34,960 --> 00:03:37,520
Another problem is that you don't
know if it works until the end.

59
00:03:37,520 --> 00:03:40,320
There is no intermediate delivery.

60
00:03:40,320 --> 00:03:42,880
Nothing is delivered, until that last step,

61
00:03:42,880 --> 00:03:46,880
when we give it to the operations team and
say, go deliver the thing to production.

62
00:03:48,080 --> 00:03:52,240
In addition, with each phase, there
are issues that are just passed down.

63
00:03:52,240 --> 00:03:55,520
And, of course, every one of
these is an opportunity to lose

64
00:03:55,520 --> 00:03:58,160
information, and to have a mishap.

65
00:03:58,160 --> 00:04:00,400
People get blocked, because they can't accept the

66
00:04:00,400 --> 00:04:03,840
work from the previous phase.
And then the next phase is delayed.

67
00:04:05,040 --> 00:04:09,680
Mistakes that are found later are very,
very costly, it is especially costly to find

68
00:04:09,680 --> 00:04:15,040
something that's designed wrong in the testing
phase and go all the way back and redesign it.

69
00:04:16,080 --> 00:04:20,400
Finally, these delays create long
lead times between deliveries.

70
00:04:21,840 --> 00:04:24,320
Also, the overall problem with Waterfall is that

71
00:04:24,320 --> 00:04:28,320
the teams are working separately, they're
unaware of their impact on each other.

72
00:04:28,320 --> 00:04:32,320
Designers are unaware of the impact on the code,
the coders are unaware of their impact on

73
00:04:32,320 --> 00:04:36,400
testing or impact on integration
before we get all the code together.

74
00:04:36,400 --> 00:04:39,200
So everybody is working in
their silos for their phase.

75
00:04:40,000 --> 00:04:44,000
And the scariest thought is that the
people who are furthest away from the code,

76
00:04:44,000 --> 00:04:49,520
the poor operations team, have to deploy
it, and run it, and manage it in production.

77
00:04:49,520 --> 00:04:53,440
They know the least about the code, and
they're the ones expected to run it.

78
00:04:55,600 --> 00:04:57,440
In this video, you learned that:

79
00:04:57,440 --> 00:05:01,200
Traditional Waterfall development creates
problems such as delays, frustration,

80
00:05:01,200 --> 00:05:06,400
long lead times, expensive late changes,
and operations managing unfamiliar code.

81
00:05:07,120 --> 00:05:08,400
And that in the past,

82
00:05:08,400 --> 00:05:12,923
software developers and operations worked
in silos, rather than working together.