1
00:00:00,200 --> 00:00:02,800
Thank you for listening and 
supporting the tekhelet journal 

2
00:00:02,800 --> 00:00:05,400
podcast. 
It is my ultimate pleasure to 

3
00:00:05,400 --> 00:00:08,800
serve you in the past two years.
I hope the podcast serves you 

4
00:00:08,800 --> 00:00:12,300
well and gives a lot of insights
that you can apply in your work 

5
00:00:12,300 --> 00:00:15,900
and Life as we are going to 
celebrate the 100th episode. 

6
00:00:16,000 --> 00:00:19,200
I would appreciate if you can 
drop a few words in our survey 

7
00:00:19,300 --> 00:00:21,800
related to your experience with 
the podcast. 

8
00:00:22,100 --> 00:00:25,600
And if you record your story or 
message in an audio format, we 

9
00:00:25,600 --> 00:00:28,200
may feature you in the podcast 
special episode. 

10
00:00:28,500 --> 00:00:31,400
The survey is open for both. 
Both listeners and guess. 

11
00:00:31,700 --> 00:00:33,600
I'm looking forward to hearing 
your message. 

12
00:00:33,600 --> 00:00:37,600
Soon, drop me the message on 
technology, know the dev slash 

13
00:00:37,700 --> 00:00:42,200
celebrate Dash 100, here's the 
link one more time, technology? 

14
00:00:42,200 --> 00:00:46,800
Know the Beth's, let's celebrate
bash, 100, what engineering 

15
00:00:46,800 --> 00:00:48,700
means? 
You know, the disciplines is the

16
00:00:48,700 --> 00:00:52,100
most effective efficient way of 
doing work of high quality. 

17
00:00:52,900 --> 00:00:56,800
And so, if software engineering,
doesn't allow us to build back 

18
00:00:56,800 --> 00:00:59,500
to software faster, it isn't 
software engineering. 

19
00:01:04,599 --> 00:01:07,300
Hey everyone. 
My name is Henry Surya, we 

20
00:01:07,300 --> 00:01:10,600
Robin. 
And you're listening to the 

21
00:01:10,600 --> 00:01:13,900
technology, you know, podcast 
the show where I'll be bringing 

22
00:01:13,900 --> 00:01:17,000
you the greatest technical 
leaders practitioners and 

23
00:01:17,000 --> 00:01:20,800
thought leaders in the industry 
to discuss about their Journey 

24
00:01:21,000 --> 00:01:25,500
ideas and practices that we all 
can learn and apply to build a 

25
00:01:25,500 --> 00:01:29,100
highly performing technical team
and to make an impact in your 

26
00:01:29,100 --> 00:01:32,300
personal work. 
So let's dive into our Journal. 

27
00:01:37,400 --> 00:01:40,600
Hello to all of you, my friends 
and listeners, welcome to this 

28
00:01:40,600 --> 00:01:43,500
special episode of the 
technology on our podcast, the 

29
00:01:43,500 --> 00:01:45,800
show where you can learn about 
technical leadership and 

30
00:01:45,800 --> 00:01:49,400
Excellence from my conversations
with great thought, leaders in 

31
00:01:49,400 --> 00:01:53,100
the tech industry and this is 
the episode number 100. 

32
00:01:53,200 --> 00:01:56,300
Oh my God, I can't believe that.
I finally reach this special 

33
00:01:56,300 --> 00:01:59,300
milestone in the beginning. 
When I started my journey 

34
00:01:59,300 --> 00:02:03,100
creating this podcast, I made a 
pledge to myself that I would 

35
00:02:03,100 --> 00:02:06,800
reach 100 episodes. 
And here we are two years later 

36
00:02:06,800 --> 00:02:10,500
from my very first episode. 
I'm really proud to have reached

37
00:02:10,500 --> 00:02:13,600
this Milestone and I could not 
have done it without the support

38
00:02:13,600 --> 00:02:17,600
from each of you, who listen to 
the episodes week in week out. 

39
00:02:17,600 --> 00:02:20,900
And also a special thanks to all
the guests, who appeared on the 

40
00:02:20,908 --> 00:02:24,000
show and for sharing your 
expertise and wisdom. 

41
00:02:24,300 --> 00:02:28,100
I really, really appreciate your
trust collaboration and for your

42
00:02:28,100 --> 00:02:30,500
willingness to share back to the
community. 

43
00:02:30,800 --> 00:02:32,600
And personally, I have grown a 
lot. 

44
00:02:32,800 --> 00:02:35,800
In the past two years by 
serving, all these great 

45
00:02:35,800 --> 00:02:38,200
contents. 
And I really hope that all of 

46
00:02:38,200 --> 00:02:40,800
you enjoy and grow yourself as 
well. 

47
00:02:41,200 --> 00:02:44,300
And by the way, if this is your 
first time, listening to tackle 

48
00:02:44,300 --> 00:02:46,400
e-journal, make sure you 
subscribe. 

49
00:02:46,400 --> 00:02:49,600
And follow the show on your 
favorite podcast app and the 

50
00:02:49,600 --> 00:02:52,600
social media on LinkedIn, 
Twitter and Instagram. 

51
00:02:53,000 --> 00:02:56,200
And for any of you who wants to 
contribute back to the creation 

52
00:02:56,200 --> 00:02:59,900
of this podcast, support my 
journey by subscribing as a 

53
00:02:59,900 --> 00:03:02,600
patron, at technology node Dev 
slash pay. 

54
00:03:02,800 --> 00:03:07,300
Patron for today's special 
episode, I am super excited to 

55
00:03:07,300 --> 00:03:10,300
share my conversation with 
another great thought leader in 

56
00:03:10,300 --> 00:03:13,700
the software industry, since I 
read his groundbreaking book, 

57
00:03:13,700 --> 00:03:15,700
continuous delivery, and 
applied. 

58
00:03:15,700 --> 00:03:18,200
Many of the principles and 
techniques mentioned in the 

59
00:03:18,200 --> 00:03:20,400
book. 
I have benefited a lot in my 

60
00:03:20,400 --> 00:03:24,100
professional career and still 
continue to Advocate its best 

61
00:03:24,100 --> 00:03:28,000
practices wherever I can. 
The book itself, one the joke 

62
00:03:28,000 --> 00:03:32,000
award in 2011 and has been 
continuously impacting the 

63
00:03:32,000 --> 00:03:34,800
industries. 
Instant even until now. 

64
00:03:35,300 --> 00:03:37,800
And so, as many of you would 
have already guessed by. 

65
00:03:37,800 --> 00:03:41,800
Now, my guest, for today's 
special episode is Dave Folly 

66
00:03:42,300 --> 00:03:45,900
apart from co-authoring, 
continuous delivery book, these 

67
00:03:45,900 --> 00:03:48,000
days. 
Dave, also runs a highly 

68
00:03:48,000 --> 00:03:51,200
successful and popular 
continuous delivery YouTube 

69
00:03:51,200 --> 00:03:55,000
channel on software engineering 
topics, which I also watch and 

70
00:03:55,000 --> 00:03:58,000
learn from it. 
A lot in this episode, we 

71
00:03:58,000 --> 00:04:01,500
discussed Dave's latest book, 
modern software engineering, 

72
00:04:02,000 --> 00:04:05,200
Dave started, It by explaining 
his view on Modern software 

73
00:04:05,200 --> 00:04:08,600
engineering and why it 
emphasizes on practices for 

74
00:04:08,600 --> 00:04:13,000
building better software faster.
Dave describe the foundations of

75
00:04:13,000 --> 00:04:15,900
the software engineering 
discipline and he explained the 

76
00:04:15,900 --> 00:04:19,100
core competencies, we need to 
succeed in modern software. 

77
00:04:19,100 --> 00:04:23,200
Engineering by becoming experts 
at both learning and managing 

78
00:04:23,200 --> 00:04:25,900
complexity. 
They've also explained the 

79
00:04:25,900 --> 00:04:29,000
importance of understanding 
technology, fundamentals, 

80
00:04:29,300 --> 00:04:32,500
improving software, readability,
and handling software. 

81
00:04:32,800 --> 00:04:37,700
Cassidy by managing concurrency,
and coupling towards the N Dave 

82
00:04:37,700 --> 00:04:40,600
also share some of the tools in 
the modern software engineering 

83
00:04:40,600 --> 00:04:44,100
tool kit that, of course, 
include continuous delivery. 

84
00:04:44,700 --> 00:04:48,000
I really enjoyed my conversation
with Dave learning the 

85
00:04:48,000 --> 00:04:50,200
fundamentals of modern software 
engineering. 

86
00:04:50,400 --> 00:04:53,900
And importantly, the practices 
that we can use for optimizing 

87
00:04:53,900 --> 00:04:55,800
learning and managing 
complexity. 

88
00:04:56,200 --> 00:04:59,800
If you also enjoy listening to 
this episode, please share it 

89
00:04:59,800 --> 00:05:02,100
with your friends and 
colleagues, who you think may 

90
00:05:02,100 --> 00:05:04,700
also benefit fit from listening 
to this episode. 

91
00:05:04,800 --> 00:05:07,900
It is my ultimate mission to 
spread this podcast to more 

92
00:05:07,900 --> 00:05:10,200
people. 
And I need your help to support 

93
00:05:10,200 --> 00:05:12,000
me towards fulfilling my 
mission. 

94
00:05:12,400 --> 00:05:15,000
Before we continue the 
conversation, let's hear some 

95
00:05:15,000 --> 00:05:18,800
words from our sponsor definitey
is the top International 

96
00:05:18,800 --> 00:05:22,200
software development conference,
with an emphasis on coding 

97
00:05:22,500 --> 00:05:24,800
architecture and Tech leadership
skills. 

98
00:05:25,100 --> 00:05:28,400
The lineup for this year is 
truly stellar and features many 

99
00:05:28,400 --> 00:05:32,200
Legends in software development 
names, such as Robert Uncle Bob 

100
00:05:32,200 --> 00:05:36,400
Martin, Kennebec Scott 
Hanselman, thank a subramanyam 

101
00:05:36,600 --> 00:05:40,500
Carolyn honey, Alan Halep, Mary,
poppendieck, and many other 

102
00:05:40,500 --> 00:05:43,800
prominent names, including some 
of those who have also appeared 

103
00:05:43,800 --> 00:05:47,800
in this podcast before the 
conference takes place online. 

104
00:05:47,900 --> 00:05:50,500
So you can enjoy it from the 
comfort of your couch. 

105
00:05:50,900 --> 00:05:53,900
We spoke to the definitey 
organizers, and I'm happy to 

106
00:05:53,900 --> 00:05:56,400
share that technology. 
You know, has got the 10% 

107
00:05:56,400 --> 00:06:02,500
discount code for you, enter the
promo code, awsm underscore tlj.

108
00:06:02,900 --> 00:06:07,000
When you purchase the ticket on 
definite e.com, here's the promo

109
00:06:07,000 --> 00:06:10,400
code. 
One more time awsm underscore, 

110
00:06:10,400 --> 00:06:13,500
tlj. 
Depending on the time when you 

111
00:06:13,500 --> 00:06:16,300
purchase a ticket early price is
still available. 

112
00:06:16,900 --> 00:06:19,600
See you there. 
Today's episode is proudly 

113
00:06:19,600 --> 00:06:23,200
sponsored by skills matter. 
The global community and events 

114
00:06:23,200 --> 00:06:25,900
platform. 
With more than 100,000 software 

115
00:06:25,900 --> 00:06:29,600
professionals here members. 
Can organize their learning 

116
00:06:29,600 --> 00:06:32,000
experiences around the 
technology topics. 

117
00:06:32,000 --> 00:06:35,000
They care about. 
At most you get on-demand access

118
00:06:35,000 --> 00:06:38,900
to their latest content thought,
leadership insights, as well as 

119
00:06:38,900 --> 00:06:42,700
the exciting schedule of tech 
events running across all time 

120
00:06:42,700 --> 00:06:45,100
zones. 
So whether devops our data 

121
00:06:45,100 --> 00:06:49,200
science is your bus or you are 
fan of functional programming or

122
00:06:49,200 --> 00:06:52,800
all things Cloud, you can make 
real connections with people who

123
00:06:52,800 --> 00:06:56,900
share your interests head on 
over to skills method or calm to

124
00:06:56,900 --> 00:06:59,700
become part of the tech 
community that matters most to 

125
00:06:59,700 --> 00:07:01,800
you. 
It's free to join and you will 

126
00:07:01,800 --> 00:07:04,300
find it easy. 
Keep up with the latest tech 

127
00:07:04,300 --> 00:07:08,200
Trends. 
Hello everyone. 

128
00:07:08,200 --> 00:07:10,500
Welcome back to another new 
episode of the technology on our

129
00:07:10,500 --> 00:07:14,300
podcast today, I'm very excited.
So I got the chance to meet 

130
00:07:14,300 --> 00:07:17,700
someone who I follow a lot by 
reading his book, following his 

131
00:07:17,700 --> 00:07:19,800
blocks. 
And also recently his YouTube 

132
00:07:19,800 --> 00:07:21,900
channel, his name is David 
Farley. 

133
00:07:22,100 --> 00:07:24,700
Also more widely known as de 
Farley. 

134
00:07:25,000 --> 00:07:27,200
I mean just to share. 
And when I read The Continuous 

135
00:07:27,200 --> 00:07:29,200
delivery book, this was like 
many years back. 

136
00:07:29,400 --> 00:07:32,600
I find that book is one of the 
Cornerstone of my career. 

137
00:07:32,900 --> 00:07:35,900
Trying to implement those 
practices like delivery pipe 

138
00:07:35,900 --> 00:07:38,900
lines, continuous integration. 
I really find the book is 

139
00:07:38,900 --> 00:07:41,400
something that is really 
critical for my journey so I 

140
00:07:41,407 --> 00:07:44,300
really thank you for that for 
writing the book and as a next 

141
00:07:44,300 --> 00:07:48,000
artwork as well I always love to
see all the other workers as an 

142
00:07:48,000 --> 00:07:50,600
author because they write a very
insightful book based on 

143
00:07:50,600 --> 00:07:52,700
experience. 
Thank you so much for spending 

144
00:07:52,700 --> 00:07:54,900
your time today. 
Dave looking forward for this 

145
00:07:54,900 --> 00:07:58,700
conversation It's a pleasure. 
Thank you very much for asking 

146
00:07:58,700 --> 00:08:00,900
me and I'm pleased that you 
enjoyed my book. 

147
00:08:02,000 --> 00:08:04,600
So in the beginning, maybe if 
you can share a little bit of 

148
00:08:04,600 --> 00:08:07,500
background about yourself, maybe
telling us your career Journey 

149
00:08:07,500 --> 00:08:10,100
that maybe people haven't heard 
about any highlights or turning 

150
00:08:10,100 --> 00:08:13,300
points, should I do? 
So, as you can probably tell by 

151
00:08:13,300 --> 00:08:16,200
looking at me, I've had quite a 
long career, I'd be doing 

152
00:08:16,200 --> 00:08:18,500
software developed for a very 
long time and Correll. 

153
00:08:18,800 --> 00:08:23,800
I started off probably at the 
start of what was then called 

154
00:08:23,800 --> 00:08:26,900
the microcomputer Revolution. 
So the Mooshroom kind of Lady 

155
00:08:26,900 --> 00:08:30,900
computers to computers that were
more accessible based on Silicon

156
00:08:30,900 --> 00:08:33,700
integrated circuits that were 
starting to become cheap. 

157
00:08:33,900 --> 00:08:37,299
So I had the advantage of kind 
of the first computers being 

158
00:08:37,299 --> 00:08:40,600
fairly simple and be kind of 
growing up with them over time, 

159
00:08:40,700 --> 00:08:43,400
which is pretty nice. 
Really, I've done quite a lot of

160
00:08:43,400 --> 00:08:45,500
different things. 
I spent the early part of my 

161
00:08:45,500 --> 00:08:47,600
career with Hardware 
manufacturers, I worked for 

162
00:08:47,608 --> 00:08:50,700
computer manufacturers and 
writing operating systems and 

163
00:08:50,700 --> 00:08:52,800
device drivers and those kinds 
of things. 

164
00:08:53,200 --> 00:08:56,300
And then later, I got 
interested, I don't know by 

165
00:08:56,300 --> 00:08:57,500
accident. 
I didn't but in kind of 

166
00:08:57,500 --> 00:09:01,300
distributed systems starting to 
build for those days larger 

167
00:09:01,300 --> 00:09:05,000
scale distributed systems, I 
think I ever shared for kind of 

168
00:09:05,000 --> 00:09:07,200
become part of the team that 
invented the concept of 

169
00:09:07,200 --> 00:09:10,300
microservices a long time before
they actually cook off. 

170
00:09:10,800 --> 00:09:12,900
So we kind of emailed them and 
then they went away again. 

171
00:09:13,200 --> 00:09:16,200
We did some really interesting 
stuff for a research company. 

172
00:09:16,400 --> 00:09:19,300
Building software with these 
very Loosely coupled. 

173
00:09:19,300 --> 00:09:21,500
We called the collaborative 
business objects. 

174
00:09:21,600 --> 00:09:24,800
It's still the most interesting 
software in the sense that you 

175
00:09:24,800 --> 00:09:27,600
could introduce two pieces of 
Independently developed 

176
00:09:27,600 --> 00:09:30,800
software, and they could do 
useful work together, which are 

177
00:09:30,800 --> 00:09:32,700
not seen, anything do that, 
quite, as well. 

178
00:09:32,900 --> 00:09:34,600
It was a fascinating project to 
work. 

179
00:09:34,600 --> 00:09:37,600
On one of the seminal moments, 
for me was, as you mentioned 

180
00:09:37,600 --> 00:09:40,300
Working For Thought Works, 
weren't you thought works, and 

181
00:09:40,300 --> 00:09:43,100
I'd already be doing informally 
some agile. 

182
00:09:43,100 --> 00:09:46,200
Things I'd be doing a little bit
extreme programming projects 

183
00:09:46,200 --> 00:09:49,100
before that but thought Works 
kind of turn the volume up on 

184
00:09:49,100 --> 00:09:52,400
that show me and we started 
doing what we thought at the 

185
00:09:52,400 --> 00:09:53,800
time. 
And I think the one most people 

186
00:09:53,800 --> 00:09:57,500
credit to Sweet are working on 
some of the Big East agile 

187
00:09:57,500 --> 00:09:59,700
projects that had been done up 
to that point. 

188
00:09:59,700 --> 00:10:01,700
And so we must are pushing the 
boundaries and finding 

189
00:10:01,700 --> 00:10:04,100
difficult, things difficult 
problems. 

190
00:10:04,100 --> 00:10:05,700
We've had you, apply extreme 
programming. 

191
00:10:05,700 --> 00:10:09,200
When you got 200 programmers, we
started addressing that kind of 

192
00:10:09,200 --> 00:10:10,800
thing. 
And I think that was one of the 

193
00:10:10,800 --> 00:10:13,900
things that sort of gave birth 
to the concepts that have 

194
00:10:13,900 --> 00:10:16,200
steered my career. 
Since in terms of continuous 

195
00:10:16,200 --> 00:10:19,100
delivery and talk to you more 
engineering, kind of approach to

196
00:10:19,108 --> 00:10:21,000
thinking about solving, these 
kind of problems. 

197
00:10:21,400 --> 00:10:24,100
The latter part of my career. 
I've spent nearly all of my 

198
00:10:24,100 --> 00:10:28,100
career building real software 
for people one way or Nova about

199
00:10:28,100 --> 00:10:31,800
six years ago, my friends and 
family convinced me that I ought

200
00:10:31,800 --> 00:10:34,300
to start my own business because
I was always a bit nervous of 

201
00:10:34,308 --> 00:10:37,600
doing that kind of thing. 
And so I started a consultancy 

202
00:10:37,600 --> 00:10:40,900
these days. 
My job really is a software 

203
00:10:40,900 --> 00:10:43,900
consultant advising 
organizations all over the 

204
00:10:43,900 --> 00:10:46,500
world. 
Usually big organizations on how

205
00:10:46,500 --> 00:10:49,800
to do a better job of software 
development and not to mention 

206
00:10:49,800 --> 00:10:52,700
also producing YouTube content. 
It gasps you seem to be very, 

207
00:10:52,700 --> 00:10:55,400
yeah, even of churning out 
contents every week. 

208
00:10:55,800 --> 00:10:58,800
Sorry to Oh it's you. 
That was some accidents as well 

209
00:10:59,000 --> 00:11:01,200
as you can probably tell. 
I'm not some weird plants are 

210
00:11:01,200 --> 00:11:04,200
career hoop. 
That was an accident forced on 

211
00:11:04,200 --> 00:11:06,900
us by the tender me. 
I was very busy with 

212
00:11:06,900 --> 00:11:09,000
consultancy. 
The pandemic happened and that 

213
00:11:09,000 --> 00:11:11,800
stopped and my wife and I were 
looking around saying, what are 

214
00:11:11,800 --> 00:11:14,400
we gonna do? 
We especially go to Brazil next 

215
00:11:14,400 --> 00:11:16,100
week, you know, probably gonna 
be there. 

216
00:11:16,400 --> 00:11:19,300
And so we started YouTube 
channel, partly just as a means 

217
00:11:19,300 --> 00:11:22,600
of keeping us sane and having 
something to do, and it's being 

218
00:11:22,600 --> 00:11:26,100
extraordinarily more successful 
than we ever anticipated or hope

219
00:11:26,100 --> 00:11:29,100
which is Not. 
I can also see the plaque behind

220
00:11:29,100 --> 00:11:32,200
you, so I think that, yeah, I 
know like after you reach some 

221
00:11:32,200 --> 00:11:34,200
hundred thousand subscribers or 
something like that. 

222
00:11:34,200 --> 00:11:35,600
Right. 
That's right. 

223
00:11:35,700 --> 00:11:38,200
So we got that earlier this 
year, we just passed a hundred 

224
00:11:38,200 --> 00:11:42,000
twenty thousand subscribers we 
rapidly approaching or we just 

225
00:11:42,000 --> 00:11:45,800
crossed the 5 million views Ma. 
So it's quite a big Channel, 

226
00:11:45,800 --> 00:11:49,200
know for a technical Channel. 
We release a video every week on

227
00:11:49,200 --> 00:11:52,000
Wednesday and we get tens of 
thousands of years. 

228
00:11:52,000 --> 00:11:54,800
Every week we usually would get 
that quarter million views a 

229
00:11:54,800 --> 00:11:56,800
month. 
That's quite a lot of people 

230
00:11:56,800 --> 00:11:59,600
coming along with the journey 
and at least listening to these 

231
00:11:59,600 --> 00:12:02,100
ideas even if they don't always 
agree with them, which is good 

232
00:12:02,100 --> 00:12:05,300
because we're back at the 
debates and it's not just about 

233
00:12:05,300 --> 00:12:07,900
the number of viewers, but I 
think the quality of the content

234
00:12:07,900 --> 00:12:11,200
at these pretty rare still, I 
rarely find YouTube videos that 

235
00:12:11,200 --> 00:12:14,300
covers all this technical 
contents, that is deep and also 

236
00:12:14,300 --> 00:12:17,000
based on real experience. 
So, thank you so much for 

237
00:12:17,000 --> 00:12:19,600
producing that and I hope that 
it will continue to grow. 

238
00:12:20,000 --> 00:12:23,000
But today, I think we will 
discuss mainly from your latest 

239
00:12:23,000 --> 00:12:25,400
book, which is titled modern 
software engineering. 

240
00:12:25,600 --> 00:12:27,400
The first thing that comes Two 
minor for me. 

241
00:12:27,400 --> 00:12:30,400
When I look at the title, why do
you call it modern software 

242
00:12:30,400 --> 00:12:32,400
engineering? 
Is there the always of software 

243
00:12:32,400 --> 00:12:34,600
engineering and there's a new 
modern way of software 

244
00:12:34,600 --> 00:12:37,700
engineering? 
Yeah, it was a total movie stuck

245
00:12:37,700 --> 00:12:40,400
in my mind for a long time while
I was writing the book and to be

246
00:12:40,400 --> 00:12:44,300
honest I was somewhat nervous. 
Like the reason that I call it 

247
00:12:44,300 --> 00:12:47,400
modern Subterranean rather than 
just software engineering and I 

248
00:12:47,408 --> 00:12:49,100
was nervous. 
Oblique lightly is kind of the 

249
00:12:49,100 --> 00:12:51,600
same. 
I think, you know industry, we 

250
00:12:51,600 --> 00:12:56,400
kind of weirdly devalued, what 
we think of as engineering I 

251
00:12:56,500 --> 00:12:59,800
It's very common to think for 
people to say, software 

252
00:12:59,800 --> 00:13:03,000
development isn't engineering 
and a lot of it isn't nothing. 

253
00:13:03,000 --> 00:13:04,800
That's fair. 
And lot of it isn't engineering,

254
00:13:05,000 --> 00:13:08,300
but in other disciplines 
engineering, doesn't mean 

255
00:13:08,300 --> 00:13:11,300
heavyweight bureaucracy, which I
think is what it tends to mean 

256
00:13:11,300 --> 00:13:13,600
to us. 
What engineering means in other 

257
00:13:13,600 --> 00:13:16,900
disciplines is the most 
effective efficient way of doing

258
00:13:16,900 --> 00:13:21,500
work of high quality. 
And so, if software engineering,

259
00:13:21,500 --> 00:13:24,700
doesn't allow us to build better
software faster, it isn't 

260
00:13:24,700 --> 00:13:28,500
software engineering. 
So modern software engineering, 

261
00:13:28,500 --> 00:13:31,300
I think he's different to what 
we're before we tried to 

262
00:13:31,300 --> 00:13:34,500
implement engineering approaches
before and they were nearly all 

263
00:13:34,500 --> 00:13:36,800
works. 
Narrowly focused on some 

264
00:13:36,800 --> 00:13:40,500
particular set of tools or 
diagramming techniques or 

265
00:13:40,500 --> 00:13:43,700
something like that and 
bureaucratic in heavyweight. 

266
00:13:43,900 --> 00:13:45,800
And that's not what I mean at 
all. 

267
00:13:45,900 --> 00:13:49,000
So, I mean almost entirely the 
opposite of that. 

268
00:13:49,100 --> 00:13:53,800
So what I was interested in part
of my background and interests, 

269
00:13:53,800 --> 00:13:55,900
my hobbies is that I'm very 
interested. 

270
00:13:56,100 --> 00:13:58,500
Science. 
I think that a reasonable 

271
00:13:58,600 --> 00:14:03,000
definition of engineering, is as
a practical implementation of 

272
00:14:03,000 --> 00:14:06,000
science. 
You apply scientific style 

273
00:14:06,000 --> 00:14:09,600
reasoning, which is Humanity's 
best approach to learning to 

274
00:14:09,600 --> 00:14:12,500
solving practical problems. 
And I think that's a reasonable 

275
00:14:12,500 --> 00:14:16,000
kind of colloquial. 
Definition of engineering, I was

276
00:14:16,000 --> 00:14:17,700
always interested in those kinds
of ideas. 

277
00:14:17,700 --> 00:14:21,100
What are the ID that we could 
point to and whatever your 

278
00:14:21,100 --> 00:14:23,600
technology, whatever? 
The problem, you're solving, 

279
00:14:23,600 --> 00:14:25,400
whatever organization that your 
work? 

280
00:14:26,400 --> 00:14:29,100
If you applied these principles,
you'd have a better chance of 

281
00:14:29,100 --> 00:14:31,600
success. 
And I thought I'd spotted some 

282
00:14:31,600 --> 00:14:34,700
of those things over time, and 
then related to continuous 

283
00:14:34,700 --> 00:14:37,400
delivery, which was my previous 
book that I worked on with Jay. 

284
00:14:37,400 --> 00:14:40,900
So humble and so on, but also 
somewhat separately. 

285
00:14:40,900 --> 00:14:43,000
But slightly different angle. 
It's kind of all fog. 

286
00:14:43,500 --> 00:14:46,400
They intersect and they're very 
reinforcing at one another but 

287
00:14:46,400 --> 00:14:49,400
they're not the same idea. 
So what were the principles that

288
00:14:49,400 --> 00:14:51,900
would allow us to do a better 
job? 

289
00:14:52,300 --> 00:14:55,100
And I thought that was what I 
was trying to explore and that's

290
00:14:55,100 --> 00:14:59,500
what Titles meant to try and 
convey the subtitle of the book 

291
00:14:59,500 --> 00:15:03,200
itself is doing what works to 
build better software faster. 

292
00:15:03,500 --> 00:15:06,000
And in your book, I also find it
quite insightful. 

293
00:15:06,000 --> 00:15:09,100
Is that you mentioned that if 
our software development 

294
00:15:09,100 --> 00:15:13,100
practices do not allow us to 
build better software faster, we

295
00:15:13,100 --> 00:15:15,700
should really change them 
because they are not enduring. 

296
00:15:16,000 --> 00:15:18,600
So please tell us more about 
this concept. 

297
00:15:18,600 --> 00:15:21,900
Why do you think so like why we 
should focus on building better 

298
00:15:21,900 --> 00:15:25,300
software faster? 
The simple answer is, why would 

299
00:15:25,300 --> 00:15:27,500
anybody want to build worse 
software slower? 

300
00:15:27,700 --> 00:15:30,200
I keep this the combination in 
part. 

301
00:15:30,500 --> 00:15:34,400
This is my kind of again 
colloquial take on the Dora 

302
00:15:34,400 --> 00:15:37,500
metrics, the metrics that come 
out of the state of debauch 

303
00:15:37,500 --> 00:15:41,200
report that give Alice a 
predictive model. 

304
00:15:41,600 --> 00:15:44,600
If you work in these kinds of 
ways and do these kinds of 

305
00:15:44,600 --> 00:15:48,000
things, you increase your 
chances of success and they are 

306
00:15:48,000 --> 00:15:52,000
based on the stability metrics, 
what's the quality of our 

307
00:15:52,000 --> 00:15:54,300
software? 
When we eat You suckering to 

308
00:15:54,300 --> 00:15:57,000
production, how often does he 
break and when it breaks, how 

309
00:15:57,000 --> 00:16:00,600
long does it take us to recover 
from the breakage and fruitful, 

310
00:16:00,800 --> 00:16:03,500
what's the efficiency with which
we can deliver software of that 

311
00:16:03,500 --> 00:16:06,000
quality? 
So that's the fast apart. 

312
00:16:06,200 --> 00:16:09,700
So working quickly, one of the 
findings from the door and 

313
00:16:09,700 --> 00:16:13,100
metrics which is important, I 
think, is that there is no 

314
00:16:13,100 --> 00:16:15,200
trade-off between speed and 
quality. 

315
00:16:15,400 --> 00:16:18,600
One of the traditional 
assumptions is that if you want 

316
00:16:18,600 --> 00:16:22,400
to build high-quality things, 
you need to go slowly what 

317
00:16:22,400 --> 00:16:26,500
Madonna reports Set is know, if 
you'd go slowly, you build 

318
00:16:26,500 --> 00:16:28,900
lower-quality things. 
And that's what the statistics 

319
00:16:28,900 --> 00:16:30,700
say. 
That's what a sociological 

320
00:16:30,800 --> 00:16:33,200
approach to measuring the 
performance of subdued. 

321
00:16:33,200 --> 00:16:36,800
Lot of teams finds the more 
barriers you put into being able

322
00:16:36,800 --> 00:16:40,000
to release change quickly, the 
worse the output. 

323
00:16:40,400 --> 00:16:42,900
So we want to be able to move 
quickly, we want to be able to 

324
00:16:42,900 --> 00:16:45,700
go faster and we want to be able
to build better software, and 

325
00:16:45,700 --> 00:16:48,000
that means that we need to be 
able to focusing on be able to 

326
00:16:48,000 --> 00:16:51,000
learn find out where mistakes 
are correct and really quickly 

327
00:16:51,000 --> 00:16:53,300
and efficient. 
And that color is, one of the 

328
00:16:53,300 --> 00:16:54,800
way. 
Which is closing with continuous

329
00:16:54,800 --> 00:16:56,900
delivery. 
Can you still use a fantastic 

330
00:16:56,900 --> 00:16:59,700
way of being able to build 
better software fast from my 

331
00:16:59,700 --> 00:17:02,000
career itself? 
I can tell that so many 

332
00:17:02,000 --> 00:17:05,099
experience from my view is that 
we build software faster in the 

333
00:17:05,099 --> 00:17:07,099
beginning. 
But since that, after a long 

334
00:17:07,099 --> 00:17:09,700
period of time, or maybe few 
months, it starts to get slower 

335
00:17:09,700 --> 00:17:12,000
and slower and maybe many people
have left. 

336
00:17:12,000 --> 00:17:15,099
They don't know about the 
context that domain problems. 

337
00:17:15,400 --> 00:17:18,400
So I think maybe some of the 
tools that we will discuss today

338
00:17:18,400 --> 00:17:21,800
can help people to really build 
better software faster like 

339
00:17:21,800 --> 00:17:24,700
continuously. 
So, You have a definition about 

340
00:17:24,700 --> 00:17:27,599
software engineering, right? 
If I can read here, is that the 

341
00:17:27,599 --> 00:17:30,000
application of empirical 
scientific approach, which you 

342
00:17:30,000 --> 00:17:32,700
mentioned in the beginning, just
now to finding efficient 

343
00:17:32,700 --> 00:17:36,200
economic Solutions. 
So, the economic Solutions here 

344
00:17:36,200 --> 00:17:39,300
is also quite interesting to 
practical problems in software. 

345
00:17:39,700 --> 00:17:41,800
I know that you will cover in 
the book that some of these 

346
00:17:41,800 --> 00:17:44,800
keywords are really important. 
Maybe if you can discuss 

347
00:17:44,800 --> 00:17:48,100
slightly some of these terms, 
why do you think it's important 

348
00:17:48,100 --> 00:17:50,500
to Define software engineering 
using this way? 

349
00:17:51,400 --> 00:17:55,500
So, I was trying to get the 
simplest minimal description of 

350
00:17:55,500 --> 00:17:57,900
what I was thinking. 
In terms of engineering. 

351
00:17:58,100 --> 00:18:00,300
I was quite pleased with that 
description that you just read 

352
00:18:00,300 --> 00:18:04,000
out because it's fairly lean. 
It's fairly concise, but I think

353
00:18:04,000 --> 00:18:05,800
he doesn't miss anything 
important. 

354
00:18:06,000 --> 00:18:10,200
So applying the reasoning, the 
rational approach of science, I 

355
00:18:10,200 --> 00:18:12,800
think that one of the 
fundamental Nature's of science 

356
00:18:12,800 --> 00:18:15,200
is that the difference is 
between science and almost. 

357
00:18:15,200 --> 00:18:18,600
Everything else is that we start
out assuming that we're probably

358
00:18:18,600 --> 00:18:20,900
wrong and that's a very healthy 
thing to do. 

359
00:18:21,000 --> 00:18:23,600
In engineering and in software 
development at all. 

360
00:18:23,900 --> 00:18:26,500
So we're going to apply 
scientific style of being in a 

361
00:18:26,500 --> 00:18:29,200
lightweight, not overburdening, 
not bureaucratic way. 

362
00:18:29,200 --> 00:18:31,800
But we're going to be informed 
by that kind of thing. 

363
00:18:32,000 --> 00:18:34,100
We're requiring. 
That solving practical problems.

364
00:18:34,100 --> 00:18:36,600
We're not doing theoretical 
researcher. 

365
00:18:36,700 --> 00:18:40,400
Proving the quarks are the basis
of particles or anything. 

366
00:18:40,600 --> 00:18:43,200
We're building things. 
And so we've got to be practical

367
00:18:43,200 --> 00:18:46,700
and pragmatic. 
So the empiricism of engineering

368
00:18:46,700 --> 00:18:49,800
just trying stuff out, 
ultimately, he's a big part of 

369
00:18:49,800 --> 00:18:53,200
it as well. 
The economic power is Again, 

370
00:18:53,200 --> 00:18:56,800
part of engineering. 
If we are physicists, we can 

371
00:18:56,800 --> 00:19:00,200
imagine building machines at a 
black hole, thinking about that 

372
00:19:00,200 --> 00:19:02,800
practically economically in 
energy terms. 

373
00:19:02,800 --> 00:19:06,400
We're not ready to do that kind 
of thing for us Engineers, we 

374
00:19:06,400 --> 00:19:09,400
are building things, and so 
there are always economically 

375
00:19:09,400 --> 00:19:13,200
strength at some level. 
That's about the amount of time 

376
00:19:13,200 --> 00:19:16,500
and effort and money that they 
spent, but also economic 

377
00:19:16,500 --> 00:19:20,000
constraints in the sense of the 
performance of our delivery 

378
00:19:20,000 --> 00:19:22,000
system and the performance. 
It's about software. 

379
00:19:22,200 --> 00:19:25,200
The carbon footprint of the 
software that we create, that 

380
00:19:25,200 --> 00:19:27,600
kind of thing. 
He's an interesting question for

381
00:19:27,600 --> 00:19:28,400
you need. 
So right. 

382
00:19:28,400 --> 00:19:30,400
So I wanted to get that in there
as well. 

383
00:19:30,600 --> 00:19:33,700
So I think all of these 
different parts of the 

384
00:19:33,700 --> 00:19:37,100
definition, kind of lead us in 
this direction of trying to 

385
00:19:37,100 --> 00:19:42,700
organize our thinking in a more 
rational way and apply it to 

386
00:19:42,700 --> 00:19:45,700
solving problems, and are of 
value to people in some way. 

387
00:19:46,000 --> 00:19:48,500
That's what I was trying to 
reach full with the definition. 

388
00:19:49,400 --> 00:19:52,000
Thanks for that explanation 
about the software engineering. 

389
00:19:52,000 --> 00:19:55,100
So I think for us, we need to 
probably redefine some of our 

390
00:19:55,100 --> 00:19:57,900
understandings of engineering is
not just writing code that works

391
00:19:57,900 --> 00:20:00,000
and deployed. 
I think that's a really good 

392
00:20:00,000 --> 00:20:01,700
point. 
One of the things that are 

393
00:20:01,700 --> 00:20:04,700
obsessed with at the moment. 
He's watching SpaceX built a 

394
00:20:04,700 --> 00:20:08,500
space Rockets to go to Mars. 
That's engineering Live on 

395
00:20:08,500 --> 00:20:11,600
YouTube, you can kind of watch 
it happening in the real world 

396
00:20:11,900 --> 00:20:15,300
that's not theoretical. 
They're evaluating their ideas, 

397
00:20:15,300 --> 00:20:17,900
their blowing spaceships off are
learning from that. 

398
00:20:18,000 --> 00:20:20,900
They're making progress. 
Final step and of the old of 

399
00:20:20,900 --> 00:20:24,000
these things, kind of coming to 
an engineering approach to 

400
00:20:24,000 --> 00:20:27,400
solving problems and thinking 
about the ways in which stuff 

401
00:20:27,400 --> 00:20:30,600
can go wrong in all of the time,
looking at how to be proved and 

402
00:20:30,600 --> 00:20:33,200
refine our designs and our 
Solutions, so that they'll 

403
00:20:33,200 --> 00:20:36,500
better fit, the problem that 
we're trying to try to solve. 

404
00:20:37,500 --> 00:20:40,300
For us to follow this definition
of stuff, engineering you 

405
00:20:40,300 --> 00:20:43,300
mentioned there are two things 
that we have to be expert at. 

406
00:20:43,500 --> 00:20:46,400
So one is actually to become 
expert at learning. 

407
00:20:46,700 --> 00:20:48,500
This comes back. 
Probably to the scientific 

408
00:20:48,500 --> 00:20:51,700
approach that you mentioned. 
If s is experts at managing 

409
00:20:51,700 --> 00:20:54,600
complexity, maybe we can cover 
one by one. 

410
00:20:54,900 --> 00:20:56,700
Let's start with experts at 
learning. 

411
00:20:57,000 --> 00:21:00,000
So you mentioned there are a few
key things like five things that

412
00:21:00,000 --> 00:21:03,000
we need to be able to practice 
in our software engineering or 

413
00:21:03,000 --> 00:21:06,200
software development day to day.
So what are those five things? 

414
00:21:07,000 --> 00:21:09,400
Yes. 
So experts at learning, let's 

415
00:21:09,400 --> 00:21:12,800
just say why that's important. 
First of all, it's to do with 

416
00:21:12,800 --> 00:21:15,300
this kind of scientific 
engineering philosophy of 

417
00:21:15,300 --> 00:21:18,700
assuming that we probably run, 
we not going to start out with 

418
00:21:18,700 --> 00:21:20,900
perfect vision. 
We're not going to be able to 

419
00:21:20,900 --> 00:21:24,800
predict the business context, 
the technical context, the 

420
00:21:24,800 --> 00:21:27,400
socio-technical context of how 
we organize ourselves to what, 

421
00:21:27,400 --> 00:21:30,500
we don't know, the results, and 
you've those things at some 

422
00:21:30,500 --> 00:21:32,600
level, we're going to get all of
those things wrong. 

423
00:21:33,000 --> 00:21:37,000
And so we want the ability to 
make progress while we don't 

424
00:21:37,000 --> 00:21:39,400
know at the start of a project 
when we don't have all of the 

425
00:21:39,400 --> 00:21:42,700
answers yet. 
Therefore we want to optimize to

426
00:21:42,700 --> 00:21:46,300
be able to learn Microsoft did 
some research into their own 

427
00:21:46,300 --> 00:21:50,200
ideas and found that two-thirds 
of their ideas produces zero or 

428
00:21:50,200 --> 00:21:53,100
negative value for the company. 
So you'd like to be able to 

429
00:21:53,100 --> 00:21:56,100
learn which with a bad ideas 
early on, if you wanted to be 

430
00:21:56,100 --> 00:21:58,200
efficient. 
So we want to optimize for be 

431
00:21:58,208 --> 00:22:00,100
able to learn all sorts of 
things. 

432
00:22:00,400 --> 00:22:03,300
What the problem is that we're 
really trying to solve what our 

433
00:22:03,300 --> 00:22:05,600
users really need to be able to 
solve that problem. 

434
00:22:05,600 --> 00:22:07,400
What a technical solution, 
Speech. 

435
00:22:07,700 --> 00:22:09,700
Does it really work? 
Is it releasable? 

436
00:22:09,700 --> 00:22:11,100
Is it compliant all those 
things? 

437
00:22:11,100 --> 00:22:14,000
You will learn ways of doing 
that and we going to work in 

438
00:22:14,000 --> 00:22:16,600
order to be able to do that. 
As you said, there are five 

439
00:22:16,600 --> 00:22:19,400
principles that underpin our 
ability to do that. 

440
00:22:19,500 --> 00:22:22,600
So, we need to work intuitively.
We need to working many small 

441
00:22:22,600 --> 00:22:25,500
steps so that we have many 
opportunities to kind of look at

442
00:22:25,500 --> 00:22:27,900
what it is that we doing and 
refine it. 

443
00:22:28,100 --> 00:22:30,700
Oh, that didn't work. 
Let's not do that anymore. 

444
00:22:31,000 --> 00:22:33,800
That kind of thing. 
We need to take feedback 

445
00:22:33,800 --> 00:22:36,100
seriously. 
We need to understand what 

446
00:22:36,100 --> 00:22:37,200
information. 
Animation. 

447
00:22:37,200 --> 00:22:39,900
We need to gather in order to be
able to determine whether our 

448
00:22:39,900 --> 00:22:43,300
ideas or our Solutions are 
useful for help whether our 

449
00:22:43,300 --> 00:22:46,400
problems are landing with our 
customers, where there are tests

450
00:22:46,400 --> 00:22:50,100
are passing or failing, we want 
to optimize great feedback to do

451
00:22:50,100 --> 00:22:52,200
that. 
We want to also be able to work 

452
00:22:52,200 --> 00:22:55,200
incrementally, want to be able 
to build systems or almost 

453
00:22:55,200 --> 00:22:58,300
evolutionarily, sort of bit by 
bit knots. 

454
00:22:58,300 --> 00:23:01,800
All in one, great, big chunk. 
So, we want to be able to deal 

455
00:23:01,800 --> 00:23:04,000
with these things more 
independently, so that we can 

456
00:23:04,000 --> 00:23:06,400
kind of carve it out in certain 
if we working on it. 

457
00:23:06,500 --> 00:23:09,900
Scale divide the work so that 
different parts of the 

458
00:23:09,900 --> 00:23:12,300
organization can work on 
different parts of the problem. 

459
00:23:12,300 --> 00:23:15,300
So working incrementally is part
of all of that. 

460
00:23:15,300 --> 00:23:17,400
We want to book. 
Experimentally. 

461
00:23:17,400 --> 00:23:21,200
If you want to start being more 
scientific, be more like 

462
00:23:21,200 --> 00:23:25,100
engineers in our approach. 
Then we should apply a little 

463
00:23:25,100 --> 00:23:28,600
bit of discipline around the way
in which we think about making 

464
00:23:28,600 --> 00:23:31,400
changes. 
And the key to that for me is to

465
00:23:31,400 --> 00:23:33,600
think experimental e. 
We want to make little 

466
00:23:33,600 --> 00:23:34,700
predictions. 
You want to say? 

467
00:23:34,700 --> 00:23:37,700
Well this is the problem that 
We're looking at the moment. 

468
00:23:38,200 --> 00:23:42,300
We think if we did this thing 
this would improve that position

469
00:23:42,300 --> 00:23:44,300
on this problem. 
How would we tell? 

470
00:23:44,300 --> 00:23:46,500
Whether that thing was or wasn't
working? 

471
00:23:47,100 --> 00:23:49,800
That's the difference between an
experiment into that step of 

472
00:23:49,800 --> 00:23:52,900
predicting, what the outcome is,
and then carrying out the tests.

473
00:23:53,200 --> 00:23:57,400
So you can think of this as a 
etched with the product. 

474
00:23:57,400 --> 00:24:01,300
We think that if we do this 
thing, it's going to improve the

475
00:24:01,300 --> 00:24:05,100
sales or this widget and we'll 
put it into production, see what

476
00:24:05,100 --> 00:24:07,600
happens or you? 
Could be as a trash. 

477
00:24:07,900 --> 00:24:10,400
All. 
I think that the coach should do

478
00:24:10,400 --> 00:24:12,900
this thing. 
If it were to do this thing, 

479
00:24:12,900 --> 00:24:15,200
this is the assertion that I 
would be able to make. 

480
00:24:15,300 --> 00:24:18,200
Then I write some code to 
fulfill that assertion, these 

481
00:24:18,200 --> 00:24:22,000
are ways of it working 
experimental e and that can. 

482
00:24:22,200 --> 00:24:24,100
And for me, has become 
pervasive. 

483
00:24:24,100 --> 00:24:27,600
That's the way that I now think 
about and practice nearly all 

484
00:24:27,600 --> 00:24:30,500
change where I can. 
So what is it that I'm trying to

485
00:24:30,500 --> 00:24:32,100
do? 
How would I understand the 

486
00:24:32,100 --> 00:24:34,300
results of this thing? 
And I'm just thinking in that 

487
00:24:34,300 --> 00:24:36,900
way, doesn't need to be 
heavyweight to be really Fast 

488
00:24:36,900 --> 00:24:40,200
really short, really efficient 
but it's just a slightly more 

489
00:24:40,200 --> 00:24:43,000
disciplined organized. 
Way of structuring, I think that

490
00:24:43,000 --> 00:24:46,100
gives us better results and the 
last one is the empirical we 

491
00:24:46,100 --> 00:24:47,600
already talked about. 
You'd be racism. 

492
00:24:47,900 --> 00:24:50,100
Engineering is about real-world 
things. 

493
00:24:50,100 --> 00:24:54,000
You cannot about some Ivory 
Tower imagination of a system. 

494
00:24:54,000 --> 00:24:57,000
It's about the reality of it. 
So we need to gather feedback 

495
00:24:57,000 --> 00:24:58,600
from production. 
We need to go to understand 

496
00:24:58,600 --> 00:25:00,800
what's really going on. 
We need to be able to make 

497
00:25:00,800 --> 00:25:04,700
practical decisions based on 
what it is that we find Elon 

498
00:25:04,700 --> 00:25:06,400
Musk. 
He's building space. 

499
00:25:06,600 --> 00:25:09,900
Citing checklist. 
I'm sure that they're doing very

500
00:25:09,900 --> 00:25:13,500
sophisticated, computer, 
simulation, but at some point, 

501
00:25:13,600 --> 00:25:16,300
it builds the pads of metal and 
that they blow it up on a test 

502
00:25:16,300 --> 00:25:19,400
and see how it works. 
That's how Engineers think, and 

503
00:25:19,400 --> 00:25:22,600
that's how they operate. 
If you look at the development 

504
00:25:22,600 --> 00:25:25,500
of any sophisticated engine, 
think about a layer of plain 

505
00:25:25,800 --> 00:25:27,500
error. 
Planes used to be incredibly 

506
00:25:27,500 --> 00:25:32,200
dangerous things in 2017. 
The equivalent of two, thirds of

507
00:25:32,200 --> 00:25:36,400
the population of the planet 
flew in commercial airliners and

508
00:25:36,500 --> 00:25:40,400
not one person died that wasn't 
possible in the early version of

509
00:25:40,400 --> 00:25:42,900
Severa planes. 
We had to go through that pain 

510
00:25:42,900 --> 00:25:46,500
of things breaking and killing 
people and say, oh well, we 

511
00:25:46,500 --> 00:25:49,800
won't do that anymore. 
Will relearn some eight is about

512
00:25:49,800 --> 00:25:54,400
work incrementally and growing 
and learning based on mistakes 

513
00:25:54,400 --> 00:25:56,900
that we make fundamentally. 
And we've got to give ourselves 

514
00:25:56,900 --> 00:25:59,300
the freedom to be able to 
operate that way and to make 

515
00:25:59,300 --> 00:26:02,700
those kinds of mistakes books 
when they occur to learn from 

516
00:26:02,700 --> 00:26:05,900
them and to correct that. 
So I think those five things 

517
00:26:06,100 --> 00:26:08,700
it's true. 
Working feedback, incrementalism

518
00:26:08,700 --> 00:26:13,100
experimentation and empiricism 
are the Cornerstone of our 

519
00:26:13,100 --> 00:26:16,700
ability, previous species to be 
up to learn, effectively and 

520
00:26:16,700 --> 00:26:19,300
efficiently. 
I can't imagine anything that we

521
00:26:19,300 --> 00:26:21,600
could consider to be engineering
with that post legs. 

522
00:26:21,900 --> 00:26:25,400
So the first third of the book 
is really about exploring. 

523
00:26:25,400 --> 00:26:29,400
Those ideas in much more detail 
in looking at each one of those 

524
00:26:29,400 --> 00:26:32,400
principles and Hunt picking 
apart and seeing how it fits 

525
00:26:32,400 --> 00:26:35,900
with software development. 
When I read these five key 

526
00:26:35,900 --> 00:26:38,300
principles, they seem to 
interrelate with each other. 

527
00:26:38,300 --> 00:26:41,800
Of course, they support each 
other and then you become expert

528
00:26:41,800 --> 00:26:45,000
at learning. 
So these days, many people, I 

529
00:26:45,000 --> 00:26:48,900
think already understand a how 
they work intuitively. 

530
00:26:48,900 --> 00:26:51,700
They probably tried to build a 
shop feedback loop and things 

531
00:26:51,700 --> 00:26:54,200
like that. 
Where does that thing go wrong? 

532
00:26:54,300 --> 00:26:57,600
Why do you think still you still
need to reiterate these kind of 

533
00:26:57,600 --> 00:27:00,200
Concepts because a jolly five 
understand correctly. 

534
00:27:00,200 --> 00:27:02,900
From the beginning, from the 
get-go is actually to adopt all 

535
00:27:02,900 --> 00:27:04,200
these kind of things, right? 
It right. 

536
00:27:04,400 --> 00:27:07,000
If incremental short feedback 
loop and there's also an 

537
00:27:07,000 --> 00:27:10,100
experimentation partway after 
the spring, maybe iteration that

538
00:27:10,100 --> 00:27:12,200
you deploy and learn from the 
customers. 

539
00:27:12,600 --> 00:27:16,100
So, why it seems like these kind
of things are still forgotten or

540
00:27:16,100 --> 00:27:20,200
maybe misunderstood, I've Had 
The Good Fortune to you during 

541
00:27:20,200 --> 00:27:23,200
the course of my career to be 
fairly close to the birth of 

542
00:27:23,200 --> 00:27:28,400
some influential, Big Ideas, my 
observation in all of those 

543
00:27:28,400 --> 00:27:30,400
circumstances. 
If you talk to the people who 

544
00:27:30,400 --> 00:27:34,100
came up with the big Ideas after
their ideas are successful, they

545
00:27:34,300 --> 00:27:37,800
said we didn't meet, man. 
That's because this kind of this

546
00:27:37,800 --> 00:27:39,900
semantic. 
Diffusion things people come up 

547
00:27:39,900 --> 00:27:43,000
with ideas and then other people
interpret them differently. 

548
00:27:43,200 --> 00:27:45,000
And I think that's definitely 
happened to Agile. 

549
00:27:45,300 --> 00:27:48,300
I think if you look at the 
agile, Manifesto, which is the 

550
00:27:48,300 --> 00:27:51,200
closest thing to a definition of
what agile really means, 

551
00:27:51,200 --> 00:27:54,500
scrubbies near the agile, 
Manifesto says, what agile is 

552
00:27:54,500 --> 00:27:57,300
really about. 
If you look at that that's not 

553
00:27:57,300 --> 00:27:59,500
going to a day that's still 
pretty good. 

554
00:27:59,600 --> 00:28:02,800
That's a pretty good 
specification of what goes on 

555
00:28:03,200 --> 00:28:06,200
the problem with a Maturity as 
an approach, an armored car 

556
00:28:06,200 --> 00:28:09,200
carrying a job. 
A believer that is an important 

557
00:28:09,200 --> 00:28:12,400
step. 
But the problem with it is that 

558
00:28:12,400 --> 00:28:15,900
part of it is about giving 
people freedom to make their own

559
00:28:15,900 --> 00:28:19,200
choices and learn things and 
that's deeply important. 

560
00:28:19,800 --> 00:28:23,200
But there are naive ways of 
taking that and one of the naive

561
00:28:23,200 --> 00:28:26,000
interpretations of that is that 
everybody has a veto on 

562
00:28:26,000 --> 00:28:28,200
everything. 
So, if you're working on a team 

563
00:28:28,200 --> 00:28:30,100
and your team decides that 
they're going to be testing 

564
00:28:30,100 --> 00:28:32,900
development, and one person on 
the team decides, they don't 

565
00:28:32,900 --> 00:28:35,400
want to do testing development. 
Don't they won't do it. 

566
00:28:35,500 --> 00:28:38,400
They'll Victory. 
That's not really what agile was

567
00:28:39,400 --> 00:28:41,100
the level at which autonomy 
works. 

568
00:28:41,100 --> 00:28:43,100
I would say is kind of at the 
level of the team. 

569
00:28:43,100 --> 00:28:44,900
So, team agree begin to work 
this way. 

570
00:28:45,000 --> 00:28:48,200
And then you do it, whether you 
like it or not, you do it up 

571
00:28:48,200 --> 00:28:50,800
that be, they're part of the 
team that was doing things that 

572
00:28:50,800 --> 00:28:52,500
I didn't speak with the right 
things to do. 

573
00:28:52,700 --> 00:28:55,200
But we still did it as a team 
because that's what we'd agreed 

574
00:28:55,200 --> 00:28:57,100
to do. 
So, there are some things like 

575
00:28:57,100 --> 00:28:59,000
that. 
There's also the natural 

576
00:28:59,000 --> 00:29:02,500
resistance of a big 
organizations to want to change,

577
00:29:02,700 --> 00:29:07,100
but I think my purpose, Over the
years, I've worked with a lot of

578
00:29:07,100 --> 00:29:10,400
different organizations usually 
bigger organizations but a lot 

579
00:29:10,400 --> 00:29:14,400
of I think my overall summary if
I could love for that it's very 

580
00:29:14,400 --> 00:29:16,800
unfair to lock the Bots. 
Get the body Force above them 

581
00:29:16,800 --> 00:29:19,000
all together. 
If I was to put words in their 

582
00:29:19,000 --> 00:29:21,300
mouths, what they all want, is 
that we'd like to carry our work

583
00:29:21,300 --> 00:29:23,000
new. 
Tack means we always did before 

584
00:29:23,200 --> 00:29:26,000
or get different results and 
that's not gonna happen. 

585
00:29:26,300 --> 00:29:30,200
So, the trouble with agile ways 
of working is that they're quite

586
00:29:30,200 --> 00:29:33,900
radically challenge to 
traditional corporate culture. 

587
00:29:34,300 --> 00:29:37,100
So they're very difficult for 
big organizations to adopt 

588
00:29:37,100 --> 00:29:40,000
because it means breaking down 
barriers in organizations 

589
00:29:40,800 --> 00:29:44,500
without sounding too immodest. 
I think the continuous delivery 

590
00:29:44,500 --> 00:29:48,900
is currently state-of-the-art 
software developed eat what most

591
00:29:48,900 --> 00:29:51,400
of the best companies in the 
world at software development to

592
00:29:51,400 --> 00:29:56,000
do and it works, you got data 
that says that it works often in

593
00:29:56,000 --> 00:29:58,800
certain measures orders of 
magnitude better than other 

594
00:29:58,800 --> 00:30:01,100
words of doing. 
And I think the one of the 

595
00:30:01,100 --> 00:30:04,000
advantages of continuous 
delivery is, it's just a little 

596
00:30:04,000 --> 00:30:05,900
bit. 
Prescriptive it still gives 

597
00:30:05,900 --> 00:30:09,900
people the freedom to innovate 
but it's fairly hard line on 

598
00:30:09,900 --> 00:30:12,700
some things. 
So part of the definition I use 

599
00:30:12,700 --> 00:30:14,800
these. 
If you can't produce something 

600
00:30:14,800 --> 00:30:17,100
releasable every day, it's not 
good. 

601
00:30:17,100 --> 00:30:19,300
English delivery that's pretty 
hard. 

602
00:30:19,300 --> 00:30:21,800
Why? 
That's a pretty definite State 

603
00:30:22,100 --> 00:30:25,800
that's more definite and say as 
important as it is but people 

604
00:30:25,800 --> 00:30:28,900
over process which the agile 
Manifesto says he's a really 

605
00:30:28,900 --> 00:30:32,400
important idea but it's a bit 
vague compared to produce 

606
00:30:32,400 --> 00:30:34,100
software of the releasable 
software. 

607
00:30:34,200 --> 00:30:35,700
Every day. 
That's a pretty hard line 

608
00:30:35,700 --> 00:30:39,600
statement, a little bit more 
constraint, a little bit more 

609
00:30:39,600 --> 00:30:41,800
specificity in what we should be
doing. 

610
00:30:42,000 --> 00:30:45,900
I think sometimes freeze us and 
helps us to be more Innovative 

611
00:30:45,900 --> 00:30:48,600
to be more creative in some of 
the things that you do. 

612
00:30:49,000 --> 00:30:51,600
I think a continuous delivery of
the second generation agile, 

613
00:30:51,600 --> 00:30:53,800
discipline. 
I think the second generation a 

614
00:30:53,808 --> 00:30:57,400
job approaches are more 
effective than the first 

615
00:30:57,400 --> 00:30:59,700
generation wants. 
So are continuously abuse. 

616
00:30:59,700 --> 00:31:03,400
Also second generation extreme 
programming for me was the best 

617
00:31:03,500 --> 00:31:05,100
agile. 
This Knights of the first 

618
00:31:05,100 --> 00:31:08,400
generation, but continuous 
delivery adds a little bit more 

619
00:31:08,400 --> 00:31:11,000
stuff around. 
Extreme programming takes a 

620
00:31:11,000 --> 00:31:13,800
little bit further, but both of 
those are engineering 

621
00:31:13,800 --> 00:31:15,500
approaches. 
And that's the other thing. 

622
00:31:15,500 --> 00:31:19,800
That is a failure of agile, 
agile, got sober T to become a 

623
00:31:19,800 --> 00:31:21,800
project management approach 
rather than an engineering 

624
00:31:21,800 --> 00:31:23,900
discipline. 
Ultimately, we're building 

625
00:31:23,900 --> 00:31:25,700
software. 
So we got to be able to create 

626
00:31:25,700 --> 00:31:27,700
things. 
However, good, you're planning, 

627
00:31:27,700 --> 00:31:32,000
he security doting, the stuff, 
it's not working at So I kind of

628
00:31:32,000 --> 00:31:34,300
like the our definition of 
continuous Delirious like a 

629
00:31:34,300 --> 00:31:37,300
second generation of a gel or 
maybe experience. 

630
00:31:37,300 --> 00:31:40,700
Because some of these practices 
is like, a rigorous process. 

631
00:31:40,900 --> 00:31:43,600
You have Department pipelines, 
running tests as driven 

632
00:31:43,600 --> 00:31:45,700
development, and all that, I 
think they're kind of, like, 

633
00:31:45,700 --> 00:31:48,900
just people guidance are so, 
what practices that they need to

634
00:31:48,900 --> 00:31:51,000
follow. 
You mention that if you cannot 

635
00:31:51,000 --> 00:31:54,400
really software every day. 
So it's a really high bar, 

636
00:31:54,500 --> 00:31:57,200
especially for people who 
started with a good idea in 

637
00:31:57,200 --> 00:32:00,800
mine, and it seems like very 
far-fetched, very high and Big 

638
00:32:00,800 --> 00:32:03,700
Ideas. 
How can people do this while at 

639
00:32:03,700 --> 00:32:05,500
the same time? 
I think one of the discussion 

640
00:32:05,500 --> 00:32:07,800
point in the book you mentioned 
about cause of change. 

641
00:32:07,800 --> 00:32:10,000
So if you're doing traditional 
software development, maybe it 

642
00:32:10,000 --> 00:32:12,300
gets faster in the beginning, 
but over the time it gets 

643
00:32:12,300 --> 00:32:14,600
slower. 
But we're using this modern 

644
00:32:14,600 --> 00:32:17,400
software engineering approach. 
You can actually make the flat 

645
00:32:17,400 --> 00:32:20,100
course of change to the software
developers. 

646
00:32:20,400 --> 00:32:23,800
So tell us more how we can 
actually aspire to reach that 

647
00:32:23,800 --> 00:32:26,600
level where over the time. 
Basically any changes you make 

648
00:32:26,600 --> 00:32:28,200
to the software is kind of like 
flat. 

649
00:32:28,200 --> 00:32:30,600
It's not like a steep curve 
going upwards. 

650
00:32:31,300 --> 00:32:35,000
I think actually that brings in 
the kind of the second section 

651
00:32:35,000 --> 00:32:37,300
of the book. 
Which is what I call managing 

652
00:32:37,300 --> 00:32:41,800
complexity, the techniques of 
managing complexity are really 

653
00:32:41,800 --> 00:32:45,200
about addressing that problem. 
So I think that one of the most 

654
00:32:45,200 --> 00:32:48,500
important qualifying 
characteristic of what, we would

655
00:32:48,500 --> 00:32:52,300
think of as quality in software,
is our ability to change it. 

656
00:32:52,700 --> 00:32:56,300
So sure it has to do the job 
that it was designed and 

657
00:32:56,300 --> 00:32:58,600
intended. 
Rory, if performance is an 

658
00:32:58,600 --> 00:33:00,900
issue, we like fast enough at 
all those kinds of benefits. 

659
00:33:00,900 --> 00:33:05,700
But fundamentally it's living in
this world where we don't know 

660
00:33:05,700 --> 00:33:08,500
all of the answers on day one. 
We can't perfectly predict the 

661
00:33:08,500 --> 00:33:09,900
future and the business 
Direction. 

662
00:33:09,900 --> 00:33:14,600
Then inevitably, we must be able
to change minds and change our 

663
00:33:14,600 --> 00:33:16,800
software. 
The business Direction might 

664
00:33:16,800 --> 00:33:18,800
change. 
That solution might not be good 

665
00:33:18,800 --> 00:33:22,500
enough in some way or another or
we spot a new idea. 

666
00:33:22,500 --> 00:33:25,200
That's much better than the one 
you had in the first person we 

667
00:33:25,200 --> 00:33:27,600
want to follow that. 
All of these are reasons to 

668
00:33:27,600 --> 00:33:31,000
change our software. 
So I think that one of the Of 

669
00:33:31,000 --> 00:33:34,400
the cornerstones of high quality
is our ability to make those 

670
00:33:34,400 --> 00:33:37,900
changes quickly fishing, the 
easily flattening that cost of 

671
00:33:37,900 --> 00:33:40,800
change curve. 
As you mentioned for that, we 

672
00:33:40,800 --> 00:33:44,200
need to be able to work a little
bit defensively, the way in 

673
00:33:44,200 --> 00:33:46,100
which we approach designer 
software. 

674
00:33:46,300 --> 00:33:49,300
So it's reinforced by the 
practices of learn, if we're 

675
00:33:49,300 --> 00:33:52,600
building our software so that we
can iterate quickly on it and we

676
00:33:52,600 --> 00:33:55,000
can gather good feedback from it
and we can carry a little 

677
00:33:55,000 --> 00:33:58,600
experiment to change to it as a 
licking experiment of some form 

678
00:33:58,600 --> 00:34:02,600
that reinforces this ability. 
Then we need to build software, 

679
00:34:02,600 --> 00:34:07,200
that's modular that's cohesive. 
The bits that are separate 

680
00:34:07,200 --> 00:34:09,600
should be separate in the 
software, the bits that are 

681
00:34:09,600 --> 00:34:11,900
closely related should be close 
together in the summer. 

682
00:34:12,300 --> 00:34:15,100
We want it to had good 
separation of concern, each 

683
00:34:15,100 --> 00:34:18,000
piece of that software to be 
focused on doing one part of the

684
00:34:18,000 --> 00:34:20,300
job. 
And then when we need to change 

685
00:34:20,300 --> 00:34:22,900
their mind on that part of the 
job, we can just work in that 

686
00:34:22,900 --> 00:34:27,100
part software. 
We want our software to lines of

687
00:34:27,100 --> 00:34:30,800
abstraction wanted to hide 
information, between one part, 

688
00:34:30,900 --> 00:34:33,300
At the software in another so we
can make change in one place. 

689
00:34:33,300 --> 00:34:35,800
So that worry too much about our
other places work. 

690
00:34:36,100 --> 00:34:38,600
Having a coupling between the 
software is a problem and 

691
00:34:38,699 --> 00:34:41,500
abstraction will give us that. 
And that is of the last point, 

692
00:34:41,500 --> 00:34:44,800
which is to manage the coupling 
effectively, but with at 

693
00:34:44,800 --> 00:34:47,900
registrants attendance, eat more
in the direction bluescope. 

694
00:34:48,199 --> 00:34:51,100
So, we'd like, at the pieces of 
our software, not to care too 

695
00:34:51,100 --> 00:34:54,600
much about the detail of all the
pieces, if we build software 

696
00:34:54,600 --> 00:34:58,300
that looks like there, then it 
is much easier to change if you 

697
00:34:58,300 --> 00:35:00,200
want to build software like 
that. 

698
00:35:00,200 --> 00:35:03,100
Then one of the It makes the 
beginning news that massively 

699
00:35:03,100 --> 00:35:06,600
amplifier is all of those five 
properties test-driven 

700
00:35:06,600 --> 00:35:09,200
development, prefers software, 
that's modular. 

701
00:35:09,200 --> 00:35:13,000
Cohesive separation of concerned
abstract and Loosely coupled, 

702
00:35:13,000 --> 00:35:15,400
it's much easier to write tests,
urine, tests or software, that 

703
00:35:15,400 --> 00:35:17,900
looks like that if you have 
those properties in the code. 

704
00:35:18,100 --> 00:35:21,700
So, we got this nice feedback 
loop, this nice reinforcing 

705
00:35:21,700 --> 00:35:24,700
process. 
We want these properties as 

706
00:35:24,700 --> 00:35:27,000
Hallmarks and quality in our 
code. 

707
00:35:27,200 --> 00:35:30,200
And we have these techniques 
that tend to make us put these 

708
00:35:30,200 --> 00:35:32,900
properties in. 
The code that's kind of what I 

709
00:35:32,908 --> 00:35:36,300
mean by engineering. 
It's not an automatic recipe. 

710
00:35:36,300 --> 00:35:39,100
It's not going to automatically 
generate great software, you 

711
00:35:39,100 --> 00:35:42,200
still need to be good, you still
need to be intelligent, still be

712
00:35:42,200 --> 00:35:44,600
to be thoughtful. 
But when you are good 

713
00:35:44,600 --> 00:35:48,100
intelligent and thoughtful and 
use these techniques, it 

714
00:35:48,100 --> 00:35:51,600
guarantees you a higher 
probability of a better outcome.

715
00:35:51,800 --> 00:35:54,800
It's not going to make sure that
you're going to be successful. 

716
00:35:54,900 --> 00:35:57,600
But you've got a higher 
probability, you will be if you 

717
00:35:57,600 --> 00:36:00,700
work those ways but big what the
data says and what I'm trying to

718
00:36:00,700 --> 00:36:03,700
do Book. 
So when you mention all these 

719
00:36:03,700 --> 00:36:06,600
five key principles, cohesion 
modularity, loose coupling 

720
00:36:06,600 --> 00:36:10,000
suppression of concern, looking 
back in the University, we kinda

721
00:36:10,000 --> 00:36:12,800
like, thought about this maybe 
in programming 101 or things 

722
00:36:12,800 --> 00:36:14,300
like that, but it's kind of 
funny. 

723
00:36:14,300 --> 00:36:17,100
Like, why do we need to keep on 
repeating these sort of 

724
00:36:17,107 --> 00:36:19,800
fundamental basic Styles in 
software engineering, probably 

725
00:36:19,800 --> 00:36:22,200
or computer science? 
You mentioned the industry 

726
00:36:22,200 --> 00:36:26,000
currently has a tendency to 
focus a lot more about tools 

727
00:36:26,000 --> 00:36:29,400
Technologies Frameworks or 
languages rather than actually 

728
00:36:29,400 --> 00:36:33,200
emphasizing a lot of fine. 
So tell us how do we get wrong 

729
00:36:33,200 --> 00:36:35,100
here? 
So many people talking about 

730
00:36:35,100 --> 00:36:38,500
Technologies like Cloud, 
kubernetes mobile, whatever that

731
00:36:38,500 --> 00:36:41,600
is, but why people the emphasize
on design? 

732
00:36:42,500 --> 00:36:46,100
It's a good question and I wish 
I knew the real answer I can 

733
00:36:46,100 --> 00:36:48,600
give you my opinions as to some 
of the Rings. 

734
00:36:49,200 --> 00:36:52,000
I think three degrees, 
inevitable software development 

735
00:36:52,000 --> 00:36:55,400
is a career appeals to certain 
kinds of people. 

736
00:36:55,500 --> 00:36:59,500
Those of us that it does appeal 
to our interesting, how 

737
00:36:59,500 --> 00:37:03,300
computers work in the tools. 
I'm as likely as anybody else to

738
00:37:03,300 --> 00:37:05,500
have a bigger wrist debate about
the merits of different 

739
00:37:05,500 --> 00:37:07,600
programming languages in a pub 
with anybody else. 

740
00:37:07,600 --> 00:37:09,400
But ultimately doesn't really 
matter. 

741
00:37:09,400 --> 00:37:13,500
Very much collapsed language 
where I thought that I'd kind of

742
00:37:13,500 --> 00:37:17,300
consciously Works to use every 
last part of the language with 

743
00:37:17,300 --> 00:37:20,200
see many years ago. 
There's not many parts to sing 

744
00:37:20,200 --> 00:37:22,200
so you can see on the bearer of 
small brand. 

745
00:37:22,500 --> 00:37:26,200
But as part of the book, I tried
to count up language like used 

746
00:37:26,400 --> 00:37:29,400
in professional settings over 
the course of my career. 

747
00:37:29,700 --> 00:37:32,700
I reckon I'll probably 
Programmed commercial software, 

748
00:37:32,700 --> 00:37:35,700
one way or another in about 20 
different languages. 

749
00:37:35,900 --> 00:37:38,700
So very ephemeral over the 
course of 40 years. 

750
00:37:39,000 --> 00:37:41,000
That's one language every couple
of years. 

751
00:37:41,700 --> 00:37:43,400
So you might be more stable than
me. 

752
00:37:43,600 --> 00:37:44,900
You might be looking at that 
more. 

753
00:37:45,100 --> 00:37:47,800
I've certainly done more stuff 
in Java than I have here 

754
00:37:47,900 --> 00:37:51,000
prologue. 
But it is interesting thinking 

755
00:37:51,000 --> 00:37:54,200
about the wet job works. 
If currencies in syntax in Java 

756
00:37:54,200 --> 00:37:57,200
and python a lot because that, 
you talked about nothing but 

757
00:37:57,200 --> 00:38:00,500
fundamentally when I stop and 
think about it doesn't have any 

758
00:38:00,500 --> 00:38:01,900
impact. 
From the way that I design 

759
00:38:01,900 --> 00:38:05,100
software area, it has some new 
arts in terms of whether I 

760
00:38:05,100 --> 00:38:07,000
medium Attic in the language 
that I'm using or not. 

761
00:38:07,000 --> 00:38:10,500
But fundamentally the way that I
organized and carve up the 

762
00:38:10,500 --> 00:38:13,200
problems that are trying to 
solve with software hasn't 

763
00:38:13,200 --> 00:38:16,700
changed very much for decades in
some ways we find around the 

764
00:38:16,700 --> 00:38:18,300
edges. 
The way that I think about is I 

765
00:38:18,300 --> 00:38:21,600
think a little bit better now 
but the same things that were 

766
00:38:21,600 --> 00:38:24,800
important doing things in C or 
even an assembler are still 

767
00:38:24,800 --> 00:38:29,000
importance during the in python 
or JavaScript so F sharp or 

768
00:38:29,008 --> 00:38:32,100
whatever else. 
Those Fundamentals, don't change

769
00:38:32,100 --> 00:38:36,500
modularity, Max's whatever the 
technology that you're using to 

770
00:38:36,500 --> 00:38:38,400
buy Cody's at the same 
separation. 

771
00:38:38,400 --> 00:38:41,100
Concerns the same. 
As you said, we learned about 

772
00:38:41,100 --> 00:38:44,000
these things in University and 
then we discard the nurse at 

773
00:38:44,000 --> 00:38:45,900
age. 
Why do this with Helm charts? 

774
00:38:46,100 --> 00:38:48,200
That stuff? 
Doesn't really better as a 

775
00:38:48,207 --> 00:38:50,500
result what we tend to do. 
So we look at something like 

776
00:38:50,500 --> 00:38:52,900
kubernetes, kubernetes is a 
fantastic tool. 

777
00:38:52,900 --> 00:38:56,800
If you're Google scale, doing 
all of these different Services.

778
00:38:57,000 --> 00:38:59,400
That's fantastic. 
I see teams. 

779
00:38:59,400 --> 00:39:03,500
All of the time that rebuilding 
Forgive me some very simple 

780
00:39:03,500 --> 00:39:06,800
little application. 
That's probably a single process

781
00:39:06,800 --> 00:39:09,700
running somewhere and they start
off by deploying you with 

782
00:39:09,700 --> 00:39:12,500
kubernetes you going. 
Why does kubernetes helpful, 

783
00:39:12,500 --> 00:39:15,400
this simple, little problem and 
is that work? 

784
00:39:15,400 --> 00:39:18,100
So thinking, in terms of what 
the problem is, that we need to 

785
00:39:18,100 --> 00:39:20,700
solve applying things like 
modularity. 

786
00:39:20,700 --> 00:39:25,700
Cohesion, separation of concerns
tells us how to solve it and 

787
00:39:25,700 --> 00:39:29,300
then we figure out the tools to 
use to apply to maximize our 

788
00:39:29,300 --> 00:39:31,600
ability to build multiple 
software, Oh, that's so easy 

789
00:39:31,600 --> 00:39:34,800
with good separation concern. 
That's the goal. 

790
00:39:35,400 --> 00:39:39,600
The technology is just, the 
means like a carpenter being 

791
00:39:39,600 --> 00:39:43,000
obsessed with the nails that 
they use and the Hammers rather 

792
00:39:43,000 --> 00:39:44,600
than what it is that they're 
building. 

793
00:39:44,900 --> 00:39:47,300
We need to focus on what it is 
that we're building. 

794
00:39:47,400 --> 00:39:50,700
Not the nails and the hammer 
thanks for giving your insights,

795
00:39:50,700 --> 00:39:53,700
like you mentioned, any good 
programmers, doesn't matter what

796
00:39:53,700 --> 00:39:56,700
language maybe they can learn 
new language or even use old 

797
00:39:56,700 --> 00:39:58,700
language. 
They can still produce software 

798
00:39:58,700 --> 00:40:00,700
that resembles all these five 
key elements. 

799
00:40:01,300 --> 00:40:04,500
Verity separation of concerns 
and things like that, the 

800
00:40:04,500 --> 00:40:07,200
importance of managing 
complexity at resonate with this

801
00:40:07,200 --> 00:40:08,900
as well. 
Because the more you have 

802
00:40:09,000 --> 00:40:12,600
growing complexity codebase the 
cost of maintaining that 

803
00:40:12,600 --> 00:40:15,900
software is really huge and we 
are probably wouldn't be able to

804
00:40:15,900 --> 00:40:19,200
make change as easy as maybe the
first time it was written in the

805
00:40:19,200 --> 00:40:21,100
last few episodes of the 
podcast. 

806
00:40:21,200 --> 00:40:23,700
I've talked with some of the 
guests about managing code, 

807
00:40:23,700 --> 00:40:26,400
complexity, readability, and all
that. 

808
00:40:26,600 --> 00:40:29,400
I think this kind of ties back 
to all these principles of 

809
00:40:29,400 --> 00:40:32,100
design. 
So why do you think it's very 

810
00:40:32,100 --> 00:40:34,600
important to have code that is 
manageable in terms of 

811
00:40:34,600 --> 00:40:37,400
complexity and also readable you
mentioned is about 

812
00:40:37,400 --> 00:40:40,600
communication, but this is 
counter-intuitive to people 

813
00:40:40,900 --> 00:40:43,600
because people think writing 
surface is to make the program 

814
00:40:43,600 --> 00:40:47,500
work or to solve a business 
problem here, and that's 

815
00:40:47,500 --> 00:40:50,800
certainly true, but it's never 
one up. 

816
00:40:51,100 --> 00:40:55,700
So this sustaining, our ability 
to solve those problems, he is 

817
00:40:55,700 --> 00:40:58,600
in everybody's interest, it's in
the interest of the 

818
00:40:58,600 --> 00:41:00,700
organisations that employers as 
well. 

819
00:41:00,900 --> 00:41:02,500
Run. 
And I think that's one of the 

820
00:41:02,508 --> 00:41:05,600
mistakes that as software 
developers on teams. 

821
00:41:05,600 --> 00:41:09,000
We tend to be too short term in 
I think and we tend to optimize 

822
00:41:09,000 --> 00:41:12,100
of next week rather than next 
month if you optimize for next 

823
00:41:12,100 --> 00:41:15,500
month that some different things
it's a bit like deciding that 

824
00:41:15,600 --> 00:41:19,600
the time that you spent putting 
Petrol in your car or charging 

825
00:41:19,600 --> 00:41:22,100
your electric car or is a waste 
of time. 

826
00:41:22,100 --> 00:41:25,000
And so you're going to do with 
that and very quickly, you're 

827
00:41:25,000 --> 00:41:27,900
going to run out of gas and you 
let your car will come grinding 

828
00:41:27,900 --> 00:41:30,400
to a halt. 
If you do that thing, there are 

829
00:41:30,408 --> 00:41:31,900
sir. 
Certain things that you need to 

830
00:41:31,900 --> 00:41:35,300
do in order to maintain your 
ability to make progress in 

831
00:41:35,300 --> 00:41:38,000
software terms. 
That's precisely what you said 

832
00:41:38,000 --> 00:41:41,200
at the start, which is the big 
problem of building complex 

833
00:41:41,200 --> 00:41:43,900
software is that over time it 
gets harder and harder to change

834
00:41:43,900 --> 00:41:45,800
it. 
That's because we didn't do a 

835
00:41:45,808 --> 00:41:49,000
good enough job of managing the 
complexity as we added new 

836
00:41:49,000 --> 00:41:52,400
things. 
So focusing all of the time on 

837
00:41:52,400 --> 00:41:55,500
managing the complexity flattens
that cost of change curve 

838
00:41:55,600 --> 00:41:59,900
retains at Freedom, to change 
our minds and to do new things 

839
00:41:59,900 --> 00:42:02,800
and new features. 
Modify the features that are 

840
00:42:02,800 --> 00:42:06,500
already there more easily. 
It might be difficult work 

841
00:42:06,500 --> 00:42:09,800
sometimes but we still have the 
ability to do that then if we 

842
00:42:09,800 --> 00:42:12,800
build some big complicated 
coupled ball of mud that we're 

843
00:42:12,800 --> 00:42:17,100
afraid to touch so managing the 
complexities about trying to 

844
00:42:17,100 --> 00:42:18,900
organize our thinking 
universities that 

845
00:42:18,900 --> 00:42:22,500
compartmentalize the problem 
it's a bit like writing a book. 

846
00:42:22,800 --> 00:42:26,600
If I wrote a book that was just 
one long sentence it might have 

847
00:42:26,600 --> 00:42:29,900
all of the same words in it but 
it'd be much much harder to read

848
00:42:30,000 --> 00:42:32,400
than if I break. 
Get down into sentences and 

849
00:42:32,400 --> 00:42:36,200
paragraphs and chapters and 
sections and label that gives us

850
00:42:36,200 --> 00:42:39,200
markers of where we are. 
We can jump to a play a 

851
00:42:39,207 --> 00:42:41,400
different part in the book. 
And look at only that part in 

852
00:42:41,400 --> 00:42:45,500
the book, I'm going to refer 
back to those are book level 

853
00:42:45,500 --> 00:42:48,600
tools for managing complexity 
ideas like modularity. 

854
00:42:48,600 --> 00:42:51,500
Cohesion, separation of concerns
abstraction and coupling. 

855
00:42:51,500 --> 00:42:55,500
Our software levels are quite 
ideas for managing complexity to

856
00:42:55,500 --> 00:42:57,900
be fair. 
I apply these not just to 

857
00:42:58,000 --> 00:43:01,200
software, but to Information 
Systems in general the way Open 

858
00:43:01,200 --> 00:43:04,300
eyes, my hard disk, he's kind of
simpler returns of modularity, 

859
00:43:04,300 --> 00:43:07,300
and cohesion and trying to break
things into pieces, and keep 

860
00:43:07,300 --> 00:43:09,800
things that are related close 
together and things that are 

861
00:43:09,800 --> 00:43:12,800
unrelated to our part of my 
dish, because it makes it easier

862
00:43:12,800 --> 00:43:16,600
for me to navigate the system. 
So, I think these ideas are 

863
00:43:16,600 --> 00:43:19,700
foundational principles that we 
should apply to basically 

864
00:43:19,700 --> 00:43:23,100
everywhere I'd be talking to 
some people building packaged 

865
00:43:23,100 --> 00:43:25,300
software and low coat software 
this. 

866
00:43:25,300 --> 00:43:27,400
Treatable still apply. 
There are be talking to people 

867
00:43:27,400 --> 00:43:30,200
to do machine learning these 
principles, still apply it. 

868
00:43:30,800 --> 00:43:33,300
I think those are the kinds of 
things that we would expect if 

869
00:43:33,300 --> 00:43:36,500
we were to identify genuinely 
important principles for an 

870
00:43:36,500 --> 00:43:38,900
engineering discipline. 
That was related to software. 

871
00:43:39,700 --> 00:43:41,700
Yeah. 
I like the way that these five 

872
00:43:41,700 --> 00:43:45,000
key principles can be actually 
taken not just from low-level 

873
00:43:45,000 --> 00:43:48,200
coat but actually do something 
bigger like machine learning and

874
00:43:48,200 --> 00:43:50,800
sometimes getting this 
distributed systems and other 

875
00:43:50,800 --> 00:43:54,600
you cover about why microservice
exist, what microservice exists 

876
00:43:54,600 --> 00:43:58,000
is partly also by adopting all 
these key principles, there are 

877
00:43:58,000 --> 00:44:00,000
two things. 
When we build a complex may be 

878
00:44:00,000 --> 00:44:01,200
distributed. 
Stubbs right? 

879
00:44:01,200 --> 00:44:04,000
You mentioned that two things 
that probably is root cause of 

880
00:44:04,000 --> 00:44:06,300
more complexities about 
concurrency. 

881
00:44:06,300 --> 00:44:09,500
And coupling sometimes these are
unconscious though, when we 

882
00:44:09,500 --> 00:44:12,200
build software we don't think 
about multi cam current process 

883
00:44:12,200 --> 00:44:14,300
at one go. 
And also coupling, it could be 

884
00:44:14,300 --> 00:44:16,600
dependency coupling, coupling 
between classes or even 

885
00:44:16,600 --> 00:44:19,500
competing with other services. 
Maybe if you can touch on these 

886
00:44:19,500 --> 00:44:22,700
two primary cause of complexity 
in the modern software. 

887
00:44:23,500 --> 00:44:26,800
Yeah, we pleasure. 
I think those two things, it 

888
00:44:26,800 --> 00:44:30,400
independently but certainly can 
bind our kind of are equivalent 

889
00:44:30,400 --> 00:44:33,900
to come Quantum physics. 
They're incredibly complicated 

890
00:44:33,900 --> 00:44:38,800
and we are always just moments 
away from which is interesting. 

891
00:44:39,000 --> 00:44:42,900
As soon as you create a branch 
in your version control system 

892
00:44:43,000 --> 00:44:46,500
or spawn a new thread, you've 
just jumped into that world of 

893
00:44:46,500 --> 00:44:50,500
complexity of concurrency and 
coupling between those 

894
00:44:50,500 --> 00:44:53,700
concurrent systems. 
And it's always comes at a much 

895
00:44:53,700 --> 00:44:57,600
bigger cause they're not doing 
and it's go back to it analogy 

896
00:44:57,600 --> 00:45:00,600
of writing a book if you and I 
are collaborating. 

897
00:45:00,900 --> 00:45:05,000
Writing a book then we could 
divide up the work and you write

898
00:45:05,000 --> 00:45:07,900
one chapter and I write another 
or if we working on the same 

899
00:45:07,900 --> 00:45:11,400
piece of text you could do so 
that we could send this changes 

900
00:45:11,400 --> 00:45:13,000
between each other and all that 
kind of stuff. 

901
00:45:13,200 --> 00:45:15,900
Or we could put it on google doc
and we could work on it could 

902
00:45:15,900 --> 00:45:20,200
currently we could see our 
changes that last one is a much 

903
00:45:20,200 --> 00:45:22,900
better way of working and much 
more efficient way of will, 

904
00:45:22,900 --> 00:45:25,200
because we can see what's going 
on and we get that fast 

905
00:45:25,200 --> 00:45:27,400
feedback, we can learn really 
quickly. 

906
00:45:27,600 --> 00:45:30,500
Oh, you're working on that part 
Henry's, working on that part. 

907
00:45:30,700 --> 00:45:33,100
I'll avoid that for now while 
he's working on, whatever it is.

908
00:45:33,100 --> 00:45:35,000
So we get much better feedback 
those way. 

909
00:45:35,300 --> 00:45:38,200
So thinking about those kinds of
ideas and how the information 

910
00:45:38,200 --> 00:45:41,700
works is important in the latter
part of my career, when I was 

911
00:45:41,700 --> 00:45:45,000
Building Systems, right? 
Talking buildings, I was 

912
00:45:45,000 --> 00:45:47,800
involved in building what we 
think was probably the world's 

913
00:45:47,800 --> 00:45:50,500
highest performance Financial 
exchange and that was 

914
00:45:50,500 --> 00:45:53,200
fascinating. 
We had to do some not 

915
00:45:53,200 --> 00:45:57,000
necessarily me but the team as a
whole had to do some really very

916
00:45:57,000 --> 00:46:00,600
clever be things in terms of 
deep concurrency and man. 

917
00:46:00,800 --> 00:46:03,400
Shooting the flow of information
to have to get the levels of 

918
00:46:03,400 --> 00:46:05,000
performance of your base to 
achieve. 

919
00:46:05,200 --> 00:46:08,600
We were looking at the specific 
architecture of Intel processors

920
00:46:08,800 --> 00:46:11,300
and designing software that 
would take advantage of that to 

921
00:46:11,300 --> 00:46:15,300
maximize the throughput of our 
Co that's very difficult stuff 

922
00:46:15,500 --> 00:46:18,400
and it's the same difficult 
stuff that we have. 

923
00:46:18,500 --> 00:46:21,300
As soon as we spawn a new 
thread, that needs to join up 

924
00:46:21,300 --> 00:46:24,600
with another trade, the cost, we
did some benchmarking kind of 

925
00:46:24,600 --> 00:46:28,100
things to look at this. 
If you just increment the number

926
00:46:28,700 --> 00:46:30,400
and you say, oh, I mean creating
this. 

927
00:46:30,700 --> 00:46:34,800
It's a very large value so I'll 
speed it up by making it to do 

928
00:46:34,800 --> 00:46:39,000
in parallel if you just do that.
Then the cost of the most 

929
00:46:39,000 --> 00:46:42,900
efficient work of synchronizing 
the results back so that you get

930
00:46:42,900 --> 00:46:47,900
a valid result at the end is 300
times slower than just doing on 

931
00:46:47,900 --> 00:46:51,000
a single thread. 
So there are naive ways of 

932
00:46:51,000 --> 00:46:54,500
optimizing things and there are 
clever ways of optimizing fixed 

933
00:46:54,700 --> 00:46:57,100
parallelism. 
He's very valuable for certain 

934
00:46:57,100 --> 00:46:59,500
kinds of problems and very 
stupid or other kinds of 

935
00:46:59,500 --> 00:47:03,100
problems one. 
The places where this surface is

936
00:47:03,400 --> 00:47:06,300
high enough, recognizable places
information control. 

937
00:47:06,600 --> 00:47:10,800
If you have a relatively coupled
system and you divide that 

938
00:47:10,800 --> 00:47:14,200
system up into a bunch of 
microservices, each living in a 

939
00:47:14,207 --> 00:47:16,800
separate repository but you 
don't trust them enough to melt 

940
00:47:16,800 --> 00:47:19,100
and release them independently. 
So you've got to test them all 

941
00:47:19,100 --> 00:47:21,200
together before you're safe to 
release. 

942
00:47:21,500 --> 00:47:23,900
That's one of the more 
inefficient ways of organizing. 

943
00:47:23,900 --> 00:47:27,400
Their if you put them all into 
one big repository, there are 

944
00:47:27,400 --> 00:47:30,200
different kinds of optimizations
that you can do then if they're 

945
00:47:30,200 --> 00:47:32,600
inseparable. 
Because the trees you are adding

946
00:47:32,600 --> 00:47:35,700
a bunch of overhead to your 
ability to go in and change 

947
00:47:35,700 --> 00:47:37,600
coding different repos, all of 
the time. 

948
00:47:37,600 --> 00:47:40,000
So it slows you down. 
There are lots of advantages to 

949
00:47:40,000 --> 00:47:43,000
microservices that they will 
give you but this is a problem 

950
00:47:43,000 --> 00:47:46,400
of concurrency and coupling 
between the these I think the 

951
00:47:46,400 --> 00:47:49,800
concurrency and coupling is the 
hardest part of software 

952
00:47:50,000 --> 00:47:52,600
computer science. 
Really everything else is 

953
00:47:52,600 --> 00:47:55,600
relatively straightforward in 
comparison to those two things. 

954
00:47:55,800 --> 00:47:59,900
So being defensive about 
concurrency and coupling is a 

955
00:47:59,900 --> 00:48:05,200
very Strategy, a couple of my 
friends are considered to be 

956
00:48:05,300 --> 00:48:08,400
world-class experts include 
current system. 

957
00:48:08,700 --> 00:48:14,000
Their advice is always dumped a 
currency unless you must, they 

958
00:48:14,000 --> 00:48:17,100
are the world's experts they 
say, don't do it unless you 

959
00:48:17,100 --> 00:48:20,100
must. 
So I think that being defensive 

960
00:48:20,100 --> 00:48:22,400
about those sorts of things and 
managing those things. 

961
00:48:22,400 --> 00:48:24,700
And one of the things that we do
that alma mater, we built our 

962
00:48:24,700 --> 00:48:27,600
very high performance exchange 
was that we are conceptually 

963
00:48:27,600 --> 00:48:30,500
isolated concurrency, so that 
didn't happen. 

964
00:48:30,600 --> 00:48:32,200
Where we were doing the business
logic. 

965
00:48:32,400 --> 00:48:36,000
So the business Logic for our 
system is very, very high 

966
00:48:36,000 --> 00:48:39,700
throughput, very widely used 
hundreds of thousands of users. 

967
00:48:40,000 --> 00:48:42,400
All the business logic was 
process on a single thread for 

968
00:48:42,400 --> 00:48:45,900
each piece of business lunch, 
but we did smark things in being

969
00:48:45,900 --> 00:48:48,500
able to bring the information to
the point at which those single 

970
00:48:48,500 --> 00:48:50,100
threads could process, the 
logic. 

971
00:48:50,200 --> 00:48:52,700
So we externalize separated the 
concerns. 

972
00:48:52,700 --> 00:48:54,900
I've been able to do that. 
So, I think there are smart ways

973
00:48:54,900 --> 00:48:57,600
of doing this in organizing, 
these kind of things, but I 

974
00:48:57,600 --> 00:49:00,400
think concurrence in coupling 
are the enemy. 

975
00:49:00,700 --> 00:49:02,800
You should be doing everything 
else to kind of God. 

976
00:49:02,800 --> 00:49:05,600
A Celtics, those things that's 
hard to be engineering 

977
00:49:05,600 --> 00:49:09,000
discipline part in managing 
complexity, thanks for sharing 

978
00:49:09,000 --> 00:49:11,000
this insights. 
I'm always amazed when in your 

979
00:49:11,000 --> 00:49:14,100
book you mention about lmax. 
This is like a very high state 

980
00:49:14,100 --> 00:49:17,300
of the art kind of system. 
Some of the principles also that

981
00:49:17,300 --> 00:49:20,200
you mention is it's not really 
just optimizing for Speed 

982
00:49:20,200 --> 00:49:22,500
paralyzing and all that your 
could must be readable. 

983
00:49:22,500 --> 00:49:25,200
But when you isolate the 
concurrency such that, you can 

984
00:49:25,200 --> 00:49:27,800
still make changes and still the
system is performing. 

985
00:49:27,800 --> 00:49:31,200
It's not like optimizing syntax 
or lines of code or try to make 

986
00:49:31,200 --> 00:49:35,500
assembly code better. 
Absolutely, 100%. 

987
00:49:35,500 --> 00:49:39,100
One of the things that we looked
at measure L Max was the 

988
00:49:39,200 --> 00:49:44,200
readable code, is nearly always 
more efficient, not because it's

989
00:49:44,200 --> 00:49:47,100
not that, it's an overhead into 
because if the code is readable 

990
00:49:47,100 --> 00:49:48,700
you're going to be striving to 
make it simple. 

991
00:49:48,700 --> 00:49:52,500
So it's expressive and clear 
what's going on and compilers, 

992
00:49:52,500 --> 00:49:55,600
love that shit. 
If the code is readable to us 

993
00:49:55,600 --> 00:49:58,600
then it's readable to compiler. 
Therefore the compiler could go 

994
00:49:58,600 --> 00:50:02,100
to town and optimize it more 
effective but more than that if 

995
00:50:02,100 --> 00:50:02,900
it's read. 
Abel. 

996
00:50:02,900 --> 00:50:06,400
It's going to be simpler and so 
there are fewer places there for

997
00:50:06,400 --> 00:50:09,900
nasty problems, too high. 
If you think about what high 

998
00:50:09,900 --> 00:50:13,500
performance software really is, 
it's about delivering the most 

999
00:50:13,500 --> 00:50:15,200
impact for the fewest 
instruction. 

1000
00:50:15,200 --> 00:50:17,700
So that's kind of definition of 
what we would think of. 

1001
00:50:17,900 --> 00:50:21,900
And so designing, for Simplicity
is really what we want. 

1002
00:50:22,100 --> 00:50:25,700
Simplicity is really what gives 
us the readability. 

1003
00:50:26,000 --> 00:50:29,000
Readability is a fantastic tool 
that will drive us in the 

1004
00:50:29,000 --> 00:50:31,500
correct direction. 
You've got to do other things so

1005
00:50:31,500 --> 00:50:34,200
I could formats as well. 
But readability, I think is one 

1006
00:50:34,200 --> 00:50:36,000
of the most profoundly important
tools. 

1007
00:50:36,000 --> 00:50:38,600
For all of those disputes of 
managing complexity. 

1008
00:50:38,800 --> 00:50:41,700
He makes that go more modular 
more cohesive, we'd better 

1009
00:50:41,700 --> 00:50:44,600
separation of concerns more 
lasting those things. 

1010
00:50:44,600 --> 00:50:47,700
Make our code more readable. 
We can build a little sentences 

1011
00:50:47,700 --> 00:50:51,700
up as we create our cone, but 
even a non-technical program, I 

1012
00:50:51,700 --> 00:50:53,600
would be able to understand what
was going on if you get the 

1013
00:50:53,607 --> 00:50:56,000
names, right? 
So I think you're right that 

1014
00:50:56,000 --> 00:50:58,000
readability is profoundly 
important. 

1015
00:50:58,100 --> 00:51:00,100
One of the real import Tools in 
our toolbox. 

1016
00:51:01,000 --> 00:51:04,300
And also on decoupling, right? 
The other source of complexity. 

1017
00:51:04,500 --> 00:51:07,100
So you mentioned just now if you
write microservice but you 

1018
00:51:07,100 --> 00:51:11,100
cannot independently release it 
or independently test it, this 

1019
00:51:11,100 --> 00:51:13,600
is also some pitfalls that 
people do they write 

1020
00:51:13,600 --> 00:51:16,500
microservice but before release 
they need to coordinate multiple

1021
00:51:16,500 --> 00:51:18,700
Services working together and do
the regression. 

1022
00:51:18,900 --> 00:51:21,300
So I learned from somewhere as 
well, that coupling is one of 

1023
00:51:21,300 --> 00:51:24,400
the killer of age Unity. 
So if you cannot manage 

1024
00:51:24,400 --> 00:51:27,100
complexity, basically, you 
cannot have this agility. 

1025
00:51:27,400 --> 00:51:29,600
Thanks for emphasizing this 
concept. 

1026
00:51:29,700 --> 00:51:33,800
So maybe if we Sometimes to 
cover the tools, the tools that 

1027
00:51:33,800 --> 00:51:36,600
you mentioned can be the modern 
software engineering tools. 

1028
00:51:36,800 --> 00:51:39,500
What are those actually tell you
mentioned about tdd continuous 

1029
00:51:39,500 --> 00:51:41,200
delivery? 
Maybe, there are some other 

1030
00:51:41,200 --> 00:51:43,700
things that we haven't learned 
from this conversation so far. 

1031
00:51:44,500 --> 00:51:46,200
Yeah. 
So there are a few other ideas. 

1032
00:51:46,600 --> 00:51:50,100
One of them is again, going back
to related to the door report if

1033
00:51:50,100 --> 00:51:54,200
we optimize our development 
approach to be able to work in 

1034
00:51:54,200 --> 00:51:57,600
smaller steps. 
So get faster feedback on our 

1035
00:51:57,600 --> 00:52:00,500
changes, we get to add more 
definitive position we can make 

1036
00:52:00,700 --> 00:52:02,700
A small change. 
Look at the effect of that 

1037
00:52:02,700 --> 00:52:06,100
change and understand it. 
Technically, I think one of the 

1038
00:52:06,100 --> 00:52:09,800
reasons why that is important is
because that's one way of 

1039
00:52:09,800 --> 00:52:14,500
limiting the variables, if we 
can make a small change and 

1040
00:52:14,500 --> 00:52:19,100
evaluate that change essentially
in its own context without 

1041
00:52:19,100 --> 00:52:21,600
worrying about the whole, the 
rest of the system that's going 

1042
00:52:21,600 --> 00:52:26,200
to give us a clearer picture of 
when the Chinese good old not as

1043
00:52:26,200 --> 00:52:29,000
long as that system is modular 
and Loosely coupled and all of 

1044
00:52:29,000 --> 00:52:32,000
those other things. 
So That's a good way of working 

1045
00:52:32,200 --> 00:52:36,000
in continuously returns speed is
probably one of the most 

1046
00:52:36,000 --> 00:52:39,600
profound tools that I use in 
trying to help big organizations

1047
00:52:39,600 --> 00:52:42,300
to transition to working with 
continuous delivery. 

1048
00:52:42,600 --> 00:52:45,100
You just start saying. 
Okay, so where are you now? 

1049
00:52:45,100 --> 00:52:48,400
You're releasing once a year. 
So let's try Andre. 

1050
00:52:48,400 --> 00:52:51,000
What would it take for us to 
releasing once every six months?

1051
00:52:51,200 --> 00:52:53,100
Let's do that. 
Then every three months, then 

1052
00:52:53,100 --> 00:52:57,000
every month, then every two 
weeks, then every week, and just

1053
00:52:57,000 --> 00:52:59,700
keep finding what the problems 
are that get in the way you use 

1054
00:52:59,700 --> 00:53:04,100
the speed of Feedback release 
ability to drive down and remove

1055
00:53:04,100 --> 00:53:07,100
work and complexity from the 
development process until you 

1056
00:53:07,100 --> 00:53:09,600
can release every day. 
That's in great way of doing 

1057
00:53:09,600 --> 00:53:11,200
things. 
It's a great way of thinking 

1058
00:53:11,200 --> 00:53:14,600
about and structuring and 
exercising changing the way that

1059
00:53:14,600 --> 00:53:19,000
people in organizations worth 
deployability is another of 

1060
00:53:19,000 --> 00:53:22,500
these fantastic tools and 
talking about micro service 

1061
00:53:22,500 --> 00:53:26,000
means kind of points to that. 
Very clear if we want to be able

1062
00:53:26,000 --> 00:53:28,700
to take an engineering stats, 
they're really what we'd like to

1063
00:53:28,700 --> 00:53:32,300
be able to do is to be as 
Trinity of as we possibly can 

1064
00:53:32,300 --> 00:53:34,700
about our evaluation of our 
software before release. 

1065
00:53:35,100 --> 00:53:38,100
So I'd like to evaluate my 
software and have as much 

1066
00:53:38,100 --> 00:53:40,400
confidence as I can achieve 
before. 

1067
00:53:40,400 --> 00:53:43,900
I release it not just put any 
old rubbish into production and 

1068
00:53:43,900 --> 00:53:46,800
red fruits fall over. 
I'd like to be able to evaluate 

1069
00:53:46,800 --> 00:53:50,500
it in as close to the 
circumstance and says I can 

1070
00:53:50,500 --> 00:53:54,200
imagine for it to be Deployable.
There are two strategies as far 

1071
00:53:54,200 --> 00:53:56,500
as I can. 
See that make sense to be able 

1072
00:53:56,500 --> 00:53:59,500
to do that. 
Both of them are driven by the 

1073
00:53:59,500 --> 00:54:01,700
deployability for supper. 
Anyway, which is why I could 

1074
00:54:01,700 --> 00:54:04,700
deploy guns is a useful tool. 
So one of them is that we could 

1075
00:54:04,700 --> 00:54:08,200
just decide that we're going to 
treat our whole system, as one 

1076
00:54:08,200 --> 00:54:10,900
thing will evaluate it all 
together. 

1077
00:54:11,200 --> 00:54:13,400
If all of our tests pass, you'll
say, yes, it's good. 

1078
00:54:13,400 --> 00:54:17,200
And we'll put into production, 
or we could decompose it into 

1079
00:54:17,300 --> 00:54:21,000
many indications of Parts. 
Evaluate these parts and say, 

1080
00:54:21,000 --> 00:54:23,900
this part is good and now that 
go to production. 

1081
00:54:24,100 --> 00:54:26,800
The second one only works as 
long as those things are 

1082
00:54:26,800 --> 00:54:29,200
independent. 
Deployable if at the end of my 

1083
00:54:29,200 --> 00:54:33,400
deployment pipeline, Say this 
part is good but now I'm going 

1084
00:54:33,400 --> 00:54:36,100
to test it with all of these 
other parts before I release it 

1085
00:54:36,400 --> 00:54:39,400
then the real pipeline. 
He's that second one where I'll 

1086
00:54:39,400 --> 00:54:41,600
be evaluating everything 
together to be able to do 

1087
00:54:41,600 --> 00:54:43,100
continuously. 
You have to be able to do that 

1088
00:54:43,100 --> 00:54:46,000
once today and there's a lot of 
complexity now because I've got 

1089
00:54:46,000 --> 00:54:48,500
all these separate, Repose and 
separate deployment pipelines. 

1090
00:54:48,500 --> 00:54:50,800
And lots of in efficiencies, 
with that way of working, 

1091
00:54:51,200 --> 00:54:53,700
microservices are independently 
Deployable. 

1092
00:54:53,900 --> 00:54:56,600
So I think you can use the 
deployability in the system as a

1093
00:54:56,607 --> 00:54:58,800
tool. 
So we can say, we want to 

1094
00:54:58,800 --> 00:55:00,500
release change into production. 
What side? 

1095
00:55:00,600 --> 00:55:04,600
Humans have deployment. 
What is this thing that I can 

1096
00:55:04,600 --> 00:55:07,500
evaluate to the point where I'm 
happy for it to go into 

1097
00:55:07,500 --> 00:55:09,300
production without doing any 
more work? 

1098
00:55:09,700 --> 00:55:12,900
What's that unit? 
That tells me the scope of your 

1099
00:55:12,900 --> 00:55:15,500
valuation of my deployment 
Pipeline and probably the scope 

1100
00:55:15,500 --> 00:55:19,300
W, goes into my repository. 
That's a useful at all the 

1101
00:55:19,300 --> 00:55:22,800
different phenotypic statement 
on how you structure your code 

1102
00:55:22,800 --> 00:55:25,900
in repositories and things like 
that scoping evaluation needs. 

1103
00:55:25,900 --> 00:55:28,800
They deploy or unit. 
All of these things, test-driven

1104
00:55:28,800 --> 00:55:31,100
development Speed release. 
Ability. 

1105
00:55:31,100 --> 00:55:35,300
All of these things are tools 
that we can use to amplify our 

1106
00:55:35,300 --> 00:55:38,400
ability to learn and our 
abilities as complexity of the 

1107
00:55:38,408 --> 00:55:40,900
systems that you build. 
So they kind of come together 

1108
00:55:40,900 --> 00:55:43,900
and that way of working. 
Amplifies, those software 

1109
00:55:43,900 --> 00:55:46,400
engineering properties, that 
we're striving to achieve. 

1110
00:55:47,000 --> 00:55:49,700
I like the way you mention about
the scope of the pipeline. 

1111
00:55:49,800 --> 00:55:51,100
So in your book, you mentioned 
that. 

1112
00:55:51,100 --> 00:55:54,000
If your pipeline says it's good,
then it's good to go. 

1113
00:55:54,200 --> 00:55:57,100
There's nothing else that you 
should wait, no approval. 

1114
00:55:57,300 --> 00:55:58,700
No coordination with other 
teams. 

1115
00:55:59,000 --> 00:56:01,900
I think that's also another key.
Insights from me, when I read 

1116
00:56:01,900 --> 00:56:04,600
the book is because sometimes 
when we have a pipeline, okay? 

1117
00:56:04,600 --> 00:56:07,200
All test, run successful and all
that, but we still wait the 

1118
00:56:07,200 --> 00:56:10,100
approval of waiting other system
to release verse or something 

1119
00:56:10,100 --> 00:56:12,200
like that. 
But the concept of good pipeline

1120
00:56:12,200 --> 00:56:14,800
is that when it's good, you just
release it, there's nothing else

1121
00:56:14,800 --> 00:56:17,800
that you should react. 
So that's one of those semantics

1122
00:56:17,800 --> 00:56:20,000
diffusions that we were talking 
about earlier. 

1123
00:56:20,800 --> 00:56:23,200
I am the person that came up 
with the idea of the deployment 

1124
00:56:23,200 --> 00:56:25,400
pipeline. 
So that's absolutely what I bet.

1125
00:56:25,400 --> 00:56:28,800
He sees Deployable at the end of
the pipeline, I tend to work in 

1126
00:56:28,800 --> 00:56:31,900
more complicated Industries. 
These Lisa regulated Industries 

1127
00:56:31,900 --> 00:56:35,600
building medical devices or 
finite systems or Machinery. 

1128
00:56:35,900 --> 00:56:38,700
The challenge there is, oh yes. 
But we got to get this sign of 

1129
00:56:38,700 --> 00:56:41,100
buying supplies. 
Know you can automate that as 

1130
00:56:41,100 --> 00:56:46,000
well as a slur made a change to 
the model 3 production line. 

1131
00:56:46,000 --> 00:56:49,600
This is a chase the factory. 
They upgrade the charging for 

1132
00:56:49,600 --> 00:56:54,900
the modern three come from 200 
kilowatts to 250 kilowatts that 

1133
00:56:54,900 --> 00:56:58,300
was a software change which 
reconfigured the factory to 

1134
00:56:58,300 --> 00:57:01,500
build cars differently and it 
took Took three hours. 

1135
00:57:01,900 --> 00:57:05,000
Wow, so they put this upgrade 
change in, he went through their

1136
00:57:05,000 --> 00:57:08,200
deployment Pipeline and then the
fatuous produces that you first 

1137
00:57:08,200 --> 00:57:13,600
about Pre-K, SpaceX are changing
software on their Rockets, 43 

1138
00:57:13,600 --> 00:57:15,100
minutes before the rocket 
launches. 

1139
00:57:15,800 --> 00:57:19,400
Wow. 
So you can do this, you can do 

1140
00:57:19,400 --> 00:57:22,800
Mission even very difficult 
circumstances, but it does take 

1141
00:57:22,800 --> 00:57:25,000
a different mindset. 
What I'm thinking was an 

1142
00:57:25,000 --> 00:57:28,600
engineering mindset to do. 
So, I'll suffer developers who 

1143
00:57:28,600 --> 00:57:31,200
listen here. 
If you think doings Liberty is 

1144
00:57:31,200 --> 00:57:34,800
hard for your software, think 
about SpaceX and Tesla and how 

1145
00:57:34,800 --> 00:57:37,500
they can do it with class 
Factory and Rockets. 

1146
00:57:37,800 --> 00:57:40,800
So I think we can all aspire to 
become much better, and try to 

1147
00:57:40,800 --> 00:57:44,400
build better software faster. 
So they've thank you so much for

1148
00:57:44,400 --> 00:57:46,700
sharing your insights all these 
conversations. 

1149
00:57:46,700 --> 00:57:49,700
I think it's really great. 
But unfortunately, due to time, 

1150
00:57:49,700 --> 00:57:52,700
we have to wrap up pretty soon. 
But I would like to ask you one 

1151
00:57:52,700 --> 00:57:54,300
last question before I let you 
go. 

1152
00:57:54,600 --> 00:57:56,300
So, this is something what I 
call tree. 

1153
00:57:56,300 --> 00:57:59,300
Technical leadership, wisdom, 
something like advice from you 

1154
00:57:59,300 --> 00:58:01,800
to all of us here. 
This Learners to learn from your

1155
00:58:01,800 --> 00:58:04,300
journey or experience or from 
your past projects. 

1156
00:58:04,500 --> 00:58:07,200
So what will be, Dave's, three 
technical leadership, is them? 

1157
00:58:08,100 --> 00:58:09,800
It's a good question. 
I think. 

1158
00:58:09,800 --> 00:58:14,300
My first one, I think the 
industry as a whole would be 

1159
00:58:14,300 --> 00:58:19,000
significantly better. 
If we all started out, assuming 

1160
00:58:19,000 --> 00:58:21,700
the are own ideas were wrong, 
rather than assuming that they 

1161
00:58:21,700 --> 00:58:24,900
were, right? 
So going thinking, this is been 

1162
00:58:24,900 --> 00:58:26,800
to be rung, but I wonder how 
it's wrong. 

1163
00:58:27,100 --> 00:58:28,800
A kick. 
That's an engineering mindset. 

1164
00:58:29,000 --> 00:58:32,300
That sets us up for Control the 
ways in which our engineering 

1165
00:58:32,300 --> 00:58:35,400
mindset is wrong, thinking about
the ways in which our software 

1166
00:58:35,400 --> 00:58:38,300
on our system isn't working 
practices can go wrong. 

1167
00:58:38,600 --> 00:58:41,100
I think that's a much better way
of organizing thing. 

1168
00:58:41,500 --> 00:58:45,200
If I could flip a switch and 
change the way that software 

1169
00:58:45,200 --> 00:58:50,100
developed worked, I would make 
it so that everybody from now on

1170
00:58:50,200 --> 00:58:53,600
that learned how to program, did
it in the context of test-driven

1171
00:58:53,600 --> 00:58:57,500
development first, their first 
day of writing their first 

1172
00:58:57,500 --> 00:58:59,800
program, they started with a 
test. 

1173
00:59:00,000 --> 00:59:03,200
That's the Way that I would 
teach test programming, because 

1174
00:59:03,200 --> 00:59:06,000
I think that if we learned 
people like that, there'd be 

1175
00:59:06,000 --> 00:59:08,100
none of these arguments about 
whether it was Bachelor, not 

1176
00:59:08,100 --> 00:59:11,300
because we know that it is. 
So I think that's the next one. 

1177
00:59:11,600 --> 00:59:16,700
The last one is I feel 
privileged to found a career 

1178
00:59:16,700 --> 00:59:20,700
that I have reveled. 
I have stained consistently even

1179
00:59:20,700 --> 00:59:24,000
on the difficult days, even when
I'm struggling, I loved what 

1180
00:59:24,000 --> 00:59:26,500
I've done for a living. 
It's fantastic. 

1181
00:59:26,700 --> 00:59:29,400
I think that we should sometimes
stop and think about that. 

1182
00:59:29,400 --> 00:59:33,300
And think about The value that 
we bring to the world, we are 

1183
00:59:33,300 --> 00:59:37,500
the engines of change in our 
society more than almost any 

1184
00:59:37,500 --> 00:59:40,300
other group of people. 
That means that we have the 

1185
00:59:40,300 --> 00:59:43,900
privilege of being in that 
position to do amazing things, 

1186
00:59:43,900 --> 00:59:47,700
like pools, and social media, 
Rigby internet, and all of that 

1187
00:59:47,700 --> 00:59:51,100
kind of stuff, which is 
fantastic on many fronts, but 

1188
00:59:51,100 --> 00:59:54,600
it's also means we have a 
responsibility to do that in a 

1189
00:59:54,607 --> 00:59:59,000
thoughtful way and worry about 
some of the implications of some

1190
00:59:59,000 --> 01:00:01,700
of these things. 
So I would also Also ask people 

1191
01:00:01,700 --> 01:00:04,900
to be a little thoughtful about 
the context in which they work 

1192
01:00:04,900 --> 01:00:07,700
his place, and that's not 
somebody else's responsibility. 

1193
01:00:08,000 --> 01:00:12,500
The Volvo emissions Scandal. 
A few years ago, showed that 

1194
01:00:12,500 --> 01:00:15,800
saying that my boss told me to 
do, this is not an excuse, the 

1195
01:00:15,800 --> 01:00:17,800
person who did it, still went to
jail. 

1196
01:00:18,200 --> 01:00:20,800
So we should be taking 
responsibility for our own 

1197
01:00:20,800 --> 01:00:23,600
working, speak about to see the 
social context to understand the

1198
01:00:23,600 --> 01:00:27,000
check. 
Well, that's really beautiful. 

1199
01:00:27,000 --> 01:00:29,100
I was guessing that you probably
will say something about 

1200
01:00:29,100 --> 01:00:32,000
continously. 
Rebut that Lee is something else

1201
01:00:32,000 --> 01:00:34,500
though Dave, I'm sure that 
people know where to look for 

1202
01:00:34,500 --> 01:00:37,000
you, but for completeness sake, 
if people want to connect with 

1203
01:00:37,000 --> 01:00:39,300
you and continue this 
conversation where they can find

1204
01:00:39,300 --> 01:00:43,000
you online, you can get me at 
Twitter, my Twitter handle is 

1205
01:00:43,000 --> 01:00:46,300
apps. 
They slowly 77, go to YouTube 

1206
01:00:46,400 --> 01:00:49,000
and search for continuous 
delivery and you will find my 

1207
01:00:49,000 --> 01:00:50,900
Chapel. 
There's some good stuff there, 

1208
01:00:50,900 --> 01:00:53,900
even though I say so much, that 
my books are available through 

1209
01:00:53,900 --> 01:00:57,000
the use of sources, you can buy 
all of my books on Amazon, one 

1210
01:00:57,000 --> 01:00:59,800
of them at least on leap. 
So, take a look for those, as 

1211
01:00:59,800 --> 01:01:01,800
well. 
Have a blog site as well date 

1212
01:01:01,800 --> 01:01:03,700
following. 
So in preparation of this 

1213
01:01:03,700 --> 01:01:06,100
composition, I must say that 
your book is really insightful, 

1214
01:01:06,100 --> 01:01:09,000
and thank you for writing that. 
I find it really good. 

1215
01:01:09,000 --> 01:01:12,100
If we all Engineers wants to 
upskill and maybe go back to the

1216
01:01:12,100 --> 01:01:15,700
basics a little bit so thinking 
about learning and also managing

1217
01:01:15,700 --> 01:01:17,800
complexity. 
So, thank you so much today for 

1218
01:01:17,800 --> 01:01:19,600
your time today. 
It was a pleasure. 

1219
01:01:20,300 --> 01:01:26,500
Thank you so much fun. 
It's not choking Thank you for 

1220
01:01:26,500 --> 01:01:29,900
listening to this episode and 
for staying, right until the end

1221
01:01:30,100 --> 01:01:33,100
if you highly enjoyed it. 
I would appreciate if you share 

1222
01:01:33,100 --> 01:01:35,400
it with your friends and 
colleagues who you think would 

1223
01:01:35,400 --> 01:01:37,800
also benefit from listening to 
this episode. 

1224
01:01:38,100 --> 01:01:40,900
And if you're new to the 
podcast, make sure to subscribe 

1225
01:01:40,900 --> 01:01:43,400
and leave me your valuable 
review and feedback. 

1226
01:01:43,600 --> 01:01:46,100
It helps me a lot. 
In order to grow this podcast 

1227
01:01:46,100 --> 01:01:48,300
better. 
You can also find the full show 

1228
01:01:48,300 --> 01:01:51,700
notes of this conversation on 
the episode page, at Tech Legion

1229
01:01:51,700 --> 01:01:56,000
o.f website, including the full 
transcript enter, In quotes and 

1230
01:01:56,000 --> 01:01:58,500
links to the resources 
mentioned, from the 

1231
01:01:58,500 --> 01:02:01,300
conversation. 
And lastly, make sure to 

1232
01:02:01,300 --> 01:02:05,000
subscribe to the shows mailing 
list on pack leader dot f to get

1233
01:02:05,000 --> 01:02:07,200
notified for any future 
episodes. 

1234
01:02:07,600 --> 01:02:09,200
Stay tuned for the next 
technology. 

1235
01:02:09,200 --> 01:02:12,000
No episode. 
And until then goodbye.