1
00:00:00,000 --> 00:00:03,000
Hey, a quick message, for those 
of you who are listening to this

2
00:00:03,000 --> 00:00:07,500
episode on Spotify, I have a 
small favor to ask Spotify. 

3
00:00:07,500 --> 00:00:11,000
Now allows mobile users to rate 
podcasts, I would really 

4
00:00:11,000 --> 00:00:13,500
appreciate it. 
If you can take a quick pass to 

5
00:00:13,500 --> 00:00:16,100
go to the technique Journal 
podcast page, and leave your 

6
00:00:16,100 --> 00:00:18,700
favorite show, your best rating 
on Spotify. 

7
00:00:19,200 --> 00:00:21,800
It will help me a lot to get 
this podcast to reach more 

8
00:00:21,800 --> 00:00:24,300
people on the platform. 
Thanks a lot. 

9
00:00:26,900 --> 00:00:30,500
Today's clip is from package, 
you know, episode 100, With day 

10
00:00:30,500 --> 00:00:33,500
Farley the one who runs the 
popular continuous delivery, 

11
00:00:33,500 --> 00:00:37,000
YouTube channel, and also the 
author of continuous delivery 

12
00:00:37,200 --> 00:00:40,500
and the latest book, modern 
software engineering in this 

13
00:00:40,500 --> 00:00:42,700
clip. 
They've explained his view on 

14
00:00:42,700 --> 00:00:45,900
Modern software engineering and 
why it emphasizes on the 

15
00:00:45,900 --> 00:00:48,900
practices for building better 
software faster. 

16
00:00:49,400 --> 00:00:51,600
They've described the 
foundations of the software 

17
00:00:51,600 --> 00:00:54,700
engineering discipline, and 
explain the core competencies. 

18
00:00:54,900 --> 00:00:58,300
We need to succeed by becoming 
experts at Learning. 

19
00:00:59,300 --> 00:01:02,100
For today, we will discuss 
mainly from your latest book, 

20
00:01:02,100 --> 00:01:04,300
which is titled modern software 
engineering. 

21
00:01:04,400 --> 00:01:07,100
The first thing that comes to 
mind for me, when I look at the 

22
00:01:07,100 --> 00:01:09,800
title, why do you call it modern
software engineering? 

23
00:01:09,800 --> 00:01:11,800
Is there the old ways of 
software engineering? 

24
00:01:11,800 --> 00:01:14,000
And there's a new modern way of 
software engineering? 

25
00:01:15,000 --> 00:01:18,000
We are able to talk with stuck 
in my mind for a long time. 

26
00:01:18,000 --> 00:01:20,300
While I was writing the book and
to be honest I was somewhat 

27
00:01:20,300 --> 00:01:24,300
nervous like the reason why I 
call it modern Subterranean 

28
00:01:24,300 --> 00:01:26,800
rather than just software 
engineering and I was nervous, 

29
00:01:26,800 --> 00:01:28,400
oblique white least kind of the 
same. 

30
00:01:28,500 --> 00:01:31,500
I think. 
Now industry, we kind of weirdly

31
00:01:31,500 --> 00:01:34,800
devalued, what we think of as 
engineering. 

32
00:01:35,100 --> 00:01:38,100
I think it's very common to 
think for people to say, 

33
00:01:38,300 --> 00:01:40,900
software development isn't 
engineering and a lot of it 

34
00:01:40,900 --> 00:01:44,200
isn't that think that's fair and
not get, isn't engineering, but 

35
00:01:44,200 --> 00:01:47,800
in other disciplines engineering
doesn't mean heavyweight 

36
00:01:47,800 --> 00:01:50,900
bureaucracy, which I think is 
what it tends to mean to us. 

37
00:01:51,300 --> 00:01:54,200
What engineering means in other 
disciplines is the most 

38
00:01:54,200 --> 00:01:57,300
effective efficient by you're 
doing work of high quality. 

39
00:01:58,100 --> 00:02:02,200
And so if software engineering 
doesn't allow us to build better

40
00:02:02,200 --> 00:02:04,700
software faster, it isn't 
software engineering. 

41
00:02:05,400 --> 00:02:08,699
So modern software engineering, 
I think he's different to what 

42
00:02:08,699 --> 00:02:11,900
we're before we tried to 
implement engineering approaches

43
00:02:11,900 --> 00:02:15,700
before and they were nearly all 
one is narrowly focused on some 

44
00:02:15,700 --> 00:02:19,400
particular set of tools or 
diagramming techniques or 

45
00:02:19,400 --> 00:02:22,600
something like that and 
bureaucratic and heavyweight. 

46
00:02:22,800 --> 00:02:24,700
And that's not what I mean at 
all. 

47
00:02:24,800 --> 00:02:27,900
So, I mean almost entirely the 
opposite of that. 

48
00:02:28,000 --> 00:02:30,600
So what are you? 
Interested in politics by 

49
00:02:30,600 --> 00:02:34,200
background and interests. 
My hobbies is that I'm very 

50
00:02:34,200 --> 00:02:37,400
interesting science. 
I think that a reasonable 

51
00:02:37,400 --> 00:02:41,900
definition of engineering is as 
a practical implementation of 

52
00:02:41,900 --> 00:02:44,900
science. 
You apply scientific style 

53
00:02:44,900 --> 00:02:48,500
reasoning, which is Humanity's 
best approach to learning to 

54
00:02:48,500 --> 00:02:51,400
solving practical problems. 
And I think that's a reasonable 

55
00:02:51,400 --> 00:02:54,000
kind of colloquial. 
Definition of engineering. 

56
00:02:54,400 --> 00:02:56,600
I was always interested in those
kinds of ideas. 

57
00:02:56,600 --> 00:02:58,900
What are the ID that we could 
point? 

58
00:02:59,000 --> 00:03:01,200
Point two and whatever your 
technology, whatever, the 

59
00:03:01,200 --> 00:03:04,400
problem you're solving, I don't 
organization that your work. 

60
00:03:05,200 --> 00:03:08,000
If you applied these principles,
you have a better chance of 

61
00:03:08,000 --> 00:03:10,500
success. 
And I thought I'd spotted some 

62
00:03:10,500 --> 00:03:13,600
of those things over time and 
they related to continuous 

63
00:03:13,600 --> 00:03:16,400
delivery which was my previous 
book that I worked on with Jay. 

64
00:03:16,400 --> 00:03:19,800
So humble and so on. 
But also somewhat separately. 

65
00:03:19,800 --> 00:03:22,600
The slightly different angle. 
It's kind of all cargo they 

66
00:03:22,600 --> 00:03:25,300
intersect and they're very 
reinforcing at one another but 

67
00:03:25,300 --> 00:03:28,100
they're not the same idea. 
So what would the principles 

68
00:03:28,100 --> 00:03:30,800
that would allow us? 
To do a better job. 

69
00:03:31,100 --> 00:03:33,800
And I thought that was what I 
was trying to explore, and 

70
00:03:33,800 --> 00:03:35,600
that's what the title is meant 
to try. 

71
00:03:35,600 --> 00:03:40,200
And convey the subtitle of the 
book itself is doing what works 

72
00:03:40,300 --> 00:03:42,200
to build that the software 
faster. 

73
00:03:42,400 --> 00:03:44,900
And in your book I also find it 
quite insightful. 

74
00:03:44,900 --> 00:03:48,000
Is that you mentioned that if 
our software development 

75
00:03:48,000 --> 00:03:51,900
practices do not allow us to 
build better software faster, we

76
00:03:52,000 --> 00:03:54,200
should really change them 
because they are not engaged 

77
00:03:54,200 --> 00:03:56,400
during. 
So please tell us more about 

78
00:03:56,400 --> 00:03:58,900
this concept. 
Why do you think so? 

79
00:03:59,000 --> 00:04:01,900
Why we should focus on building 
better software faster? 

80
00:04:02,700 --> 00:04:05,400
The simple answer is, why would 
anybody want to build were 

81
00:04:05,400 --> 00:04:08,600
software slower? 
I think it's the combination in 

82
00:04:08,600 --> 00:04:10,600
car. 
This is my corner. 

83
00:04:10,600 --> 00:04:14,800
Again, colloquial take on the 
Dora metrics, the metrics that 

84
00:04:14,800 --> 00:04:17,100
come out of the state of 
debauchery court. 

85
00:04:17,100 --> 00:04:22,100
That give us a predictive model,
if you work in these kinds of 

86
00:04:22,100 --> 00:04:24,600
ways and do these kinds of 
things, you increase your 

87
00:04:24,600 --> 00:04:29,300
chances of success and they are 
based on the stability met X. 

88
00:04:29,600 --> 00:04:31,600
What's the quality of our 
software? 

89
00:04:31,800 --> 00:04:34,400
When we introduced our current 
production, how often does he 

90
00:04:34,400 --> 00:04:36,000
break? 
And when it breaks, how long 

91
00:04:36,000 --> 00:04:39,500
does it take us to recover from 
the breakage and throughput? 

92
00:04:39,800 --> 00:04:42,400
What's the efficiency with which
we can deliver software of that 

93
00:04:42,400 --> 00:04:44,800
quality? 
So that's the faster part. 

94
00:04:45,100 --> 00:04:48,600
So working quickly, one of the 
findings from the door and 

95
00:04:48,600 --> 00:04:52,100
metrics which is important, I 
think is that there is no 

96
00:04:52,100 --> 00:04:54,100
trade-off between speed and 
quality. 

97
00:04:54,300 --> 00:04:57,500
One of the traditional 
assumptions is that if you want 

98
00:04:57,500 --> 00:05:01,300
to build high-quality, Things, 
you need to go slowly what 

99
00:05:01,300 --> 00:05:05,400
Medora report says is know, if 
you'd go slowly, you build 

100
00:05:05,400 --> 00:05:07,900
lower-quality things and that's 
what the statistics say. 

101
00:05:07,900 --> 00:05:11,200
That's what a sociological 
approach to measuring the 

102
00:05:11,200 --> 00:05:14,100
performance of subdued. 
Lot of teams finds the more 

103
00:05:14,100 --> 00:05:17,500
barriers you put into being able
to release change quickly, the 

104
00:05:17,500 --> 00:05:20,600
worse the output. 
So we want to be able to move 

105
00:05:20,600 --> 00:05:23,100
quickly, we want to be able to 
go faster, and we want to be 

106
00:05:23,100 --> 00:05:25,700
able to build better software, 
and that means that we need to 

107
00:05:25,700 --> 00:05:27,800
be able to focusing on be able 
to learn, find out where 

108
00:05:27,800 --> 00:05:31,200
mistakes are To in really 
quickly and efficient and that 

109
00:05:31,200 --> 00:05:33,600
kind of these, one of the ways 
we displayed in with continuous 

110
00:05:33,600 --> 00:05:36,300
delivery, can you still use a 
fantastic way of being able to 

111
00:05:36,300 --> 00:05:39,500
build better software fast from 
my career itself? 

112
00:05:39,500 --> 00:05:42,600
I can tell that there's so many 
experience from my view, is that

113
00:05:42,600 --> 00:05:45,600
we build software faster in the 
beginning, but since that, after

114
00:05:45,600 --> 00:05:48,200
a long period of time, or maybe 
few months, it starts to get 

115
00:05:48,200 --> 00:05:50,900
slower and slower. 
And maybe many people have left.

116
00:05:50,900 --> 00:05:54,000
They don't know about the 
context that domain problems. 

117
00:05:54,300 --> 00:05:57,300
So, I think maybe some of the 
tools that we will discuss today

118
00:05:57,300 --> 00:06:00,700
can help people to really build 
better software faster like 

119
00:06:00,700 --> 00:06:03,500
continuously. 
So, you have a definition about 

120
00:06:03,500 --> 00:06:06,400
software engineering, right? 
If I can read here, is that the 

121
00:06:06,400 --> 00:06:08,800
application of empirical 
scientific approach, which you 

122
00:06:08,800 --> 00:06:11,600
mentioned in the beginning, just
now to finding efficient 

123
00:06:11,600 --> 00:06:15,100
economic Solutions. 
So, the economic Solutions here 

124
00:06:15,100 --> 00:06:18,200
is also quite interesting to 
practical problems in software. 

125
00:06:18,500 --> 00:06:21,200
I know that you'll cover in the 
book that some of these keywords

126
00:06:21,200 --> 00:06:23,700
are really important. 
Maybe if you can discuss 

127
00:06:23,700 --> 00:06:26,900
slightly some of these terms, 
why do you think it's important 

128
00:06:26,900 --> 00:06:29,300
to Define software engineering 
using Sweet. 

129
00:06:30,300 --> 00:06:34,400
So, I was trying to get the 
simplest minimal description of 

130
00:06:34,400 --> 00:06:36,800
what I was thinking. 
In terms of engineering. 

131
00:06:37,000 --> 00:06:39,200
I was quite pleased with that 
description that you just read 

132
00:06:39,200 --> 00:06:42,900
out because it's fairly lean. 
It's fairly concise, but I think

133
00:06:42,900 --> 00:06:44,500
he doesn't miss anything 
important. 

134
00:06:44,900 --> 00:06:49,000
So applying the reasoning, the 
rational approach of science, I 

135
00:06:49,000 --> 00:06:51,900
think that one of the 
fundamental nature of science is

136
00:06:51,900 --> 00:06:54,100
that the difference is between 
science and almost. 

137
00:06:54,100 --> 00:06:57,500
Everything else is that we start
out assuming that we're probably

138
00:06:57,500 --> 00:07:01,100
wrong and that's a very Healthy 
thing to do in engineering, and 

139
00:07:01,100 --> 00:07:03,700
in such a development at all. 
So we're going to apply 

140
00:07:03,700 --> 00:07:07,100
scientific style thing in a 
lightweight, not overburdening, 

141
00:07:07,100 --> 00:07:09,600
not bureaucratic way. 
But we're going to be informed 

142
00:07:09,600 --> 00:07:12,000
by that kind of thing. 
We're applying at solving 

143
00:07:12,000 --> 00:07:14,700
practical problems. 
We're not doing theoretical 

144
00:07:14,700 --> 00:07:17,200
researcher. 
Proving the quarks are the 

145
00:07:17,200 --> 00:07:20,600
basics of particles or anything.
We're building things. 

146
00:07:20,600 --> 00:07:23,000
And so we've got to be practical
and pragmatic. 

147
00:07:23,300 --> 00:07:27,000
So the empiricism of engineering
just trying stuff out, 

148
00:07:27,000 --> 00:07:31,700
ultimately, it is a big part. 
Well, the economic part is 

149
00:07:31,700 --> 00:07:35,700
Again, part of engineering. 
If we are physicists, we can 

150
00:07:35,700 --> 00:07:39,100
imagine building machines at a 
black hole, thinking about that 

151
00:07:39,100 --> 00:07:41,700
practically economically in 
energy terms. 

152
00:07:41,700 --> 00:07:45,100
We're not ready to do that kind 
of for us Engineers. 

153
00:07:45,100 --> 00:07:48,300
We are building things and so 
there are always economic 

154
00:07:48,300 --> 00:07:52,100
Straits at some level. 
That's about the amount of time 

155
00:07:52,100 --> 00:07:55,400
and effort and money that they 
spent, but also economic 

156
00:07:55,400 --> 00:07:58,700
constraints in the sense of the 
performance of our delivery. 

157
00:07:58,900 --> 00:08:01,800
Assistant and the performance of
our software, the carbon 

158
00:08:01,800 --> 00:08:04,700
footprint of the software that 
we create, that kind of thing. 

159
00:08:05,000 --> 00:08:07,300
He's an interesting question for
you need sewn, right? 

160
00:08:07,300 --> 00:08:09,300
So I wanted to get that in there
as well. 

161
00:08:09,500 --> 00:08:12,600
So I think all of these 
different parts of the 

162
00:08:12,600 --> 00:08:16,000
definition, kind of leaders in 
this direction of trying to 

163
00:08:16,000 --> 00:08:21,600
organize our thinking in a more 
rational way and apply it to 

164
00:08:21,600 --> 00:08:24,600
solving problems, and are of 
value to people in some way. 

165
00:08:25,000 --> 00:08:27,400
That's what I was trying to 
reach full with the definition. 

166
00:08:28,200 --> 00:08:30,900
Thanks for that explanation 
about the software engineering. 

167
00:08:30,900 --> 00:08:34,000
So, I think for us, we need to 
probably redefine some of our 

168
00:08:34,000 --> 00:08:36,700
understandings of engineering is
not just writing code that works

169
00:08:36,700 --> 00:08:38,900
and deploy it. 
I think that's a really good 

170
00:08:38,900 --> 00:08:40,600
point. 
One of the things that are 

171
00:08:40,600 --> 00:08:43,600
obsessed with at the moment, 
he's watching SpaceX build their

172
00:08:43,600 --> 00:08:47,400
space Rockets to go to Mars. 
That's engineering Live on 

173
00:08:47,400 --> 00:08:50,500
YouTube, you can kind of watch 
it happening in the real world, 

174
00:08:50,800 --> 00:08:54,200
that's not theoretical. 
They're evaluating their ideas, 

175
00:08:54,200 --> 00:08:56,700
their blowing spaceships off are
learning from that. 

176
00:08:56,900 --> 00:09:00,100
They're making progress. 
My step and I think all of these

177
00:09:00,100 --> 00:09:03,200
things kind of coming to an 
engineering approach to solving 

178
00:09:03,200 --> 00:09:07,000
problems and thinking about the 
ways in which stuff can go wrong

179
00:09:07,000 --> 00:09:10,300
and all of the time looking at 
out of he proved and refine our 

180
00:09:10,300 --> 00:09:12,800
designs and a solution so that 
they'll better fit. 

181
00:09:12,800 --> 00:09:15,400
The problem that we're trying to
try to solve. 

182
00:09:16,400 --> 00:09:19,200
For us to follow this definition
of stuff, engineering you 

183
00:09:19,200 --> 00:09:22,200
mentioned there are two things 
that we have to be expert at. 

184
00:09:22,400 --> 00:09:25,300
So one is actually to become 
expert at learning. 

185
00:09:25,600 --> 00:09:27,400
This comes back. 
Probably to the scientific 

186
00:09:27,400 --> 00:09:30,600
approach that you mentioned. 
If s is experts at managing 

187
00:09:30,600 --> 00:09:33,500
complexity, maybe we can cover 
one by one. 

188
00:09:33,800 --> 00:09:35,500
Let's start with experts at 
learning. 

189
00:09:35,900 --> 00:09:38,900
So you mentioned there are a few
key things like five things that

190
00:09:38,900 --> 00:09:41,900
we need to be able to practice 
in our software engineering or 

191
00:09:41,900 --> 00:09:45,100
software development day to day.
So what are those five things? 

192
00:09:45,900 --> 00:09:50,100
Yes, so experts learning, let's 
just like War I that support, 

193
00:09:50,100 --> 00:09:53,100
first of all it's to do with 
this kind of scientific 

194
00:09:53,100 --> 00:09:55,600
engineering philosophy of 
assuming that we probably wrong,

195
00:09:55,900 --> 00:09:58,500
we not going to start out with 
perfect vision. 

196
00:09:58,800 --> 00:10:01,800
We're not going to be able to 
predict the business context, 

197
00:10:01,800 --> 00:10:05,300
the technical context, the 
socio-technical context of how 

198
00:10:05,300 --> 00:10:07,700
we organize ourselves to what, 
we don't know the results, and 

199
00:10:07,700 --> 00:10:10,800
you both think at some level, 
we're going to get all of those 

200
00:10:10,800 --> 00:10:13,900
things wrong. 
And so we want the ability to 

201
00:10:13,900 --> 00:10:17,100
make progress while we Open the 
at the start of the project 

202
00:10:17,100 --> 00:10:19,000
where we don't have all of the 
answers yet. 

203
00:10:19,400 --> 00:10:23,900
Therefore we want to optimize to
be able to learn Microsoft, did 

204
00:10:23,900 --> 00:10:27,200
some research into their own 
ideas and found that two-thirds 

205
00:10:27,200 --> 00:10:30,800
of their ideas produces zero or 
negative value for the company. 

206
00:10:31,100 --> 00:10:33,500
Single black female to learn 
which with a bad idea. 

207
00:10:33,500 --> 00:10:35,700
So early on, if you wanted to be
efficient. 

208
00:10:35,900 --> 00:10:39,000
So we want to optimize for Gail 
to learn all sorts of things. 

209
00:10:39,300 --> 00:10:42,200
What the problem is that we're 
really trying to solve what our 

210
00:10:42,200 --> 00:10:44,500
users really need to have to 
solve that problem. 

211
00:10:44,500 --> 00:10:47,600
Why technical In fits. 
Does it really work? 

212
00:10:47,600 --> 00:10:49,400
Is it releasable? 
Is it comply? 

213
00:10:49,400 --> 00:10:51,400
All those things? 
You'll learn ways of doing that.

214
00:10:51,600 --> 00:10:54,000
Are we going to work in order to
be able to do that? 

215
00:10:54,100 --> 00:10:57,200
As you said, there are five 
principles that underpin, our 

216
00:10:57,200 --> 00:11:00,000
ability to do that. 
So, we need to work iteratively.

217
00:11:00,000 --> 00:11:02,800
We need to working many small 
steps so that we have many 

218
00:11:02,800 --> 00:11:06,000
opportunities to connect. 
Look at what it is, the v2e and 

219
00:11:06,000 --> 00:11:08,300
refine it. 
Oh that didn't work. 

220
00:11:08,300 --> 00:11:10,800
Let's not do that anymore. 
That kind of thing. 

221
00:11:11,000 --> 00:11:13,400
We need to take feedback 
seriously. 

222
00:11:13,400 --> 00:11:15,500
We need to understand what 
information. 

223
00:11:15,600 --> 00:11:18,500
Should we need to gather in 
order to help determine whether 

224
00:11:18,500 --> 00:11:21,700
our ideas or our Solutions are 
useful for help? 

225
00:11:21,700 --> 00:11:24,500
Whether our products are landing
with our customers, where there 

226
00:11:24,500 --> 00:11:28,000
are tests are passing or 
failing, we want to optimize 

227
00:11:28,000 --> 00:11:31,100
great feedback to do that. 
We want to also be able to work 

228
00:11:31,100 --> 00:11:34,100
incrementally, want to be able 
to build systems or almost 

229
00:11:34,100 --> 00:11:37,200
evolutionarily. 
So, it's a bit by bit knots. 

230
00:11:37,200 --> 00:11:40,700
All in one, great, big chunk. 
So we want to be able to deal 

231
00:11:40,700 --> 00:11:42,900
with these things more 
independently so that we can 

232
00:11:42,900 --> 00:11:45,400
kind of car be as in certain if 
we working on big. 

233
00:11:45,600 --> 00:11:48,800
Scale divide up the work so that
different parts of the 

234
00:11:48,800 --> 00:11:51,200
organization can work on 
different parts of the problem. 

235
00:11:51,200 --> 00:11:55,600
So working incrementally is part
of all of that we want to work 

236
00:11:55,600 --> 00:11:58,100
experimental e. 
If you want to start being more 

237
00:11:58,100 --> 00:12:01,700
scientific, be more like 
engineers in our approach. 

238
00:12:01,700 --> 00:12:06,400
Then we should apply a little 
bit of discipline around the way

239
00:12:06,400 --> 00:12:08,200
in which we think about making 
changes. 

240
00:12:08,200 --> 00:12:11,400
And the key to that for me is to
think experimental e. 

241
00:12:11,400 --> 00:12:13,200
We want to make little 
predictions. 

242
00:12:13,200 --> 00:12:15,400
You want to say? 
Well this is the problem that we

243
00:12:15,400 --> 00:12:17,800
are. 
Looking at the moment we think 

244
00:12:17,800 --> 00:12:21,500
if we did this thing this would 
improve that position on this 

245
00:12:21,500 --> 00:12:23,200
problem. 
How would we tell? 

246
00:12:23,200 --> 00:12:26,400
Whether that thing was and 
wasn't working, that's the 

247
00:12:26,400 --> 00:12:29,300
difference between an experiment
into that step of predicting, 

248
00:12:29,300 --> 00:12:31,800
what the outcome is. 
And then carrying out the tests.

249
00:12:32,200 --> 00:12:36,200
So you could think of this as a 
etched with the product. 

250
00:12:36,200 --> 00:12:40,200
We think that if we do this 
thing, it's going to improve the

251
00:12:40,200 --> 00:12:43,800
sales or this region and will 
put it into production. 

252
00:12:43,800 --> 00:12:46,600
See what happens or you can. 
Give it as a test. 

253
00:12:46,800 --> 00:12:50,300
I think that the coach should do
this thing. 

254
00:12:50,500 --> 00:12:53,000
If it were to do this thing, 
this is the assertion that I 

255
00:12:53,000 --> 00:12:55,400
would be able to make. 
Then I write some code to 

256
00:12:55,400 --> 00:12:58,100
fulfill that assertion, these 
are ways of it working 

257
00:12:58,100 --> 00:13:03,000
experimental e and that can. 
And for me has become pervasive.

258
00:13:03,000 --> 00:13:06,500
That's the way that I now think 
about and practice nearly all 

259
00:13:06,500 --> 00:13:09,400
change where I can. 
So what is it that I'm trying to

260
00:13:09,400 --> 00:13:11,000
do? 
How would I understand the 

261
00:13:11,000 --> 00:13:13,200
results of this thing? 
And I'm just thinking in that 

262
00:13:13,200 --> 00:13:15,900
way, doesn't need to be heavy 
weight, can be really Really 

263
00:13:15,900 --> 00:13:19,700
short really efficient but it's 
just a slightly more disciplined

264
00:13:19,700 --> 00:13:21,900
organized. 
Way of structuring, I think that

265
00:13:21,900 --> 00:13:25,000
gives us better results and the 
last one is the empirical we 

266
00:13:25,000 --> 00:13:28,000
already talked about your cases 
and Engineering is about 

267
00:13:28,000 --> 00:13:31,300
real-world things. 
It's not about some Ivory Tower 

268
00:13:31,300 --> 00:13:34,400
imagination of a system. 
It's about the reality of it. 

269
00:13:34,600 --> 00:13:36,500
So we need to gather feedback 
from production. 

270
00:13:36,500 --> 00:13:38,500
We need to go to understand 
what's really going on. 

271
00:13:38,500 --> 00:13:41,400
We need to be able to make 
practical decisions based on 

272
00:13:41,400 --> 00:13:45,400
what it is that we find Elon 
Musk is building space. 

273
00:13:45,500 --> 00:13:48,800
Setting check this. 
I'm sure that they're doing very

274
00:13:48,800 --> 00:13:52,600
sophisticated computer 
simulation, but at some point it

275
00:13:52,600 --> 00:13:55,200
builds the beds of metal and 
that they blow it up on a test 

276
00:13:55,200 --> 00:13:58,300
and see how it works. 
That's how Engineers speak and 

277
00:13:58,300 --> 00:14:01,500
that's how they operate. 
If you look at the developments 

278
00:14:01,500 --> 00:14:04,400
on any sophisticated end in 
think about an aeroplane 

279
00:14:04,800 --> 00:14:09,500
aeroplanes used to be incredibly
dangerous things in 2017. 

280
00:14:09,500 --> 00:14:12,800
The equivalent of two, thirds of
the population of the planet 

281
00:14:12,800 --> 00:14:18,100
flew in commercial airliners and
One person died that wasn't 

282
00:14:18,100 --> 00:14:20,100
possible in the early versions 
of ever played. 

283
00:14:20,300 --> 00:14:23,600
We have to go through that pain 
of things breaking and killing 

284
00:14:23,600 --> 00:14:25,900
people. 
And so, when we won't do that 

285
00:14:25,900 --> 00:14:30,000
anymore, will relearn. 
So 8 is about what incrementally

286
00:14:30,000 --> 00:14:33,800
and growing, and learning based 
on mistakes that we make 

287
00:14:33,800 --> 00:14:35,800
fundamentally. 
And we've got to give ourselves 

288
00:14:35,800 --> 00:14:38,200
that freedom to be able to 
operate that way and to make 

289
00:14:38,200 --> 00:14:41,600
those kinds of mistakes books 
when they occur to learn from 

290
00:14:41,600 --> 00:14:45,200
them and to correct them. 
So I think those five things its

291
00:14:45,200 --> 00:14:48,900
roots If working feedback, 
incrementalism experimentation 

292
00:14:48,900 --> 00:14:52,600
and empiricism are the 
Cornerstone of our ability, 

293
00:14:52,600 --> 00:14:55,600
previous, a species to be able 
to learn effectively and 

294
00:14:55,600 --> 00:14:58,100
efficiently. 
I can't imagine anything that we

295
00:14:58,108 --> 00:15:00,500
could consider to be engineering
without those things. 

296
00:15:00,800 --> 00:15:04,300
So the first third of the book 
is really about exploring. 

297
00:15:04,300 --> 00:15:08,300
Those ideas in much more detail 
in looking at each one of those 

298
00:15:08,300 --> 00:15:11,300
principles and kind of picking 
apart and seeing how it fits 

299
00:15:11,300 --> 00:15:16,400
with software development. 
I hope you enjoyed this short 

300
00:15:16,400 --> 00:15:18,800
clip from pagli Journal favorite
playlist. 

301
00:15:18,900 --> 00:15:21,300
If you find this episode useful,
please help. 

302
00:15:21,300 --> 00:15:23,900
Share it with your friends and 
colleagues who you think would 

303
00:15:23,900 --> 00:15:26,400
also benefit from listening to 
this episode. 

304
00:15:26,700 --> 00:15:30,000
And if you want to listen more 
from this conversation, please 

305
00:15:30,000 --> 00:15:33,000
go back and listen to the 
original full conversation with 

306
00:15:33,000 --> 00:15:36,500
my guest, stay tuned for the 
next technology, no episode. 

307
00:15:36,500 --> 00:15:38,200
And until then goodbye.