1
00:00:00,040 --> 00:00:02,920
Hey, a quick message for those 
of you who are listening to this

2
00:00:02,920 --> 00:00:06,280
episode on Spotify. 
I have a small favor to ask. 

3
00:00:06,640 --> 00:00:10,080
Spotify now allows mobile users 
to rate podcasts. 

4
00:00:10,320 --> 00:00:13,680
I would really appreciate it if 
you can take a quick pause to go

5
00:00:13,680 --> 00:00:16,120
to the Technically Journal 
podcast page and leave your 

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

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

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

9
00:00:26,800 --> 00:00:27,840
So one thing. 
That I noticed. 

10
00:00:27,840 --> 00:00:29,680
When you mentioned. 
In the beginning, before you 

11
00:00:29,680 --> 00:00:32,240
read these three things, is. 
You mentioned the books have 

12
00:00:32,240 --> 00:00:35,280
been written like 12. 
Years ago and there are still 

13
00:00:35,280 --> 00:00:38,160
some things that are timeless 
and this is something that you 

14
00:00:38,160 --> 00:00:41,400
mentioned before we had this 
talk that we can all learn from 

15
00:00:41,400 --> 00:00:43,680
the past. 
There are many things that stays

16
00:00:43,680 --> 00:00:45,480
relevant. 
There are many things that stays

17
00:00:45,480 --> 00:00:48,600
true even till now. 
So what will be some top key 

18
00:00:48,600 --> 00:00:52,640
lessons from the past that you 
think we as programmers covering

19
00:00:52,640 --> 00:00:55,280
the old programmers and new 
programmers should know? 

20
00:00:55,480 --> 00:00:57,800
Why are the things from the past
there still stays relevant? 

21
00:00:58,360 --> 00:01:00,040
So let's go back to origin 
story. 

22
00:01:00,040 --> 00:01:03,080
So I read a lot of books when I 
got into software development 

23
00:01:03,080 --> 00:01:05,920
was at the end of the 1980s, 
which is quite a long time ago, 

24
00:01:06,320 --> 00:01:07,920
and the world has changed quite 
a lot since then. 

25
00:01:08,440 --> 00:01:12,520
The books that my boss had were 
from the 1980s and the 1970s, 

26
00:01:12,600 --> 00:01:15,080
and I read a lot of these 
things, so they were kind of 

27
00:01:15,080 --> 00:01:16,440
already historical, a lot of 
them. 

28
00:01:17,160 --> 00:01:22,000
But what I found was a 
surprisingly timeless quality to

29
00:01:22,480 --> 00:01:24,120
some of the books and their 
advice. 

30
00:01:24,520 --> 00:01:27,560
So I was brought up on a lot of 
ideas about how to think about 

31
00:01:27,560 --> 00:01:30,000
code in terms of cohesion and 
coupling. 

32
00:01:30,400 --> 00:01:33,120
We are losing these message. 
People have got distracted by 

33
00:01:33,120 --> 00:01:36,360
guidelines that don't emphasize 
these properly or have watered 

34
00:01:36,360 --> 00:01:39,840
them down in a particular way. 
Cohesion and coupling. 

35
00:01:39,840 --> 00:01:43,280
Cohesion, the degree to which 
things cohere and naturally hold

36
00:01:43,280 --> 00:01:44,720
together. 
Now, sometimes people kind of 

37
00:01:44,720 --> 00:01:46,480
say, oh, isn't that the Single 
Responsibility Principle? 

38
00:01:46,480 --> 00:01:48,560
Well, not really. 
It the kind of cohesion. 

39
00:01:48,640 --> 00:01:51,600
It's not about responsibilities.
The original quote is the Single

40
00:01:51,600 --> 00:01:53,600
Responsibility Principle is 
actually about single reason for

41
00:01:53,600 --> 00:01:54,720
change. 
It's nothing to do with 

42
00:01:54,720 --> 00:01:56,480
responsibilities. 
So naming is hard. 

43
00:01:56,480 --> 00:01:59,560
We know that single reason for 
change, but what does that 

44
00:01:59,560 --> 00:02:01,240
actually mean? 
It doesn't really mean much. 

45
00:02:01,240 --> 00:02:04,040
It's a kind of cohesion, but 
there are other kinds of 

46
00:02:04,040 --> 00:02:06,320
cohesion. 
So why people have got fixated 

47
00:02:06,320 --> 00:02:09,320
on one kind of cohesion to the 
exclusion of others, I don't 

48
00:02:09,320 --> 00:02:11,200
understand. 
We should be teaching people 

49
00:02:11,200 --> 00:02:13,800
about cohesion. 
And then again, if we look at 

50
00:02:13,800 --> 00:02:16,400
things like the SOLID principles
or many of the principles people

51
00:02:16,480 --> 00:02:19,280
describe, they don't talk about 
coupling, In other words, 

52
00:02:19,280 --> 00:02:21,720
dependency management, the 
degree to which things connect. 

53
00:02:22,000 --> 00:02:25,880
And we have far more 
dependencies in Co bases now. 

54
00:02:26,240 --> 00:02:27,960
And for some people when they 
talk about dependencies, they 

55
00:02:27,960 --> 00:02:29,560
are talking about external 
dependencies. 

56
00:02:29,600 --> 00:02:31,240
And you sort of say, oh, 
dependency management. 

57
00:02:31,240 --> 00:02:32,680
Yeah. 
And they show you all their 

58
00:02:32,680 --> 00:02:34,760
external dependencies. 
Like, yeah, you've got half a 

59
00:02:34,760 --> 00:02:36,320
million lines of code here. 
I'm talking about the 

60
00:02:36,320 --> 00:02:39,200
dependencies in the code base, 
not just outside the code base. 

61
00:02:39,440 --> 00:02:42,040
Some people kind of ended up 
kind of losing track of that. 

62
00:02:42,040 --> 00:02:45,400
So coupling, cohesion, these are
ideas in the 1970s. 

63
00:02:45,440 --> 00:02:48,040
They do not go away. 
They are fundamental. 

64
00:02:48,040 --> 00:02:49,760
There's a lot of things people 
have been trying to push as 

65
00:02:49,760 --> 00:02:52,000
fundamental. 
Those are coupling. 

66
00:02:52,000 --> 00:02:54,640
Cohesion are for us. 
They are for our benefit. 

67
00:02:55,000 --> 00:02:56,040
But by the way, the code doesn't
care. 

68
00:02:56,280 --> 00:02:58,120
The compiler's just going to 
compile what you give it. 

69
00:02:58,120 --> 00:02:59,600
It doesn't care about coupling 
cohesion. 

70
00:02:59,920 --> 00:03:02,560
The processor you're running on 
doesn't care about coupling 

71
00:03:02,560 --> 00:03:04,080
cohesion. 
It's just going to execute what 

72
00:03:04,080 --> 00:03:07,240
you say, coupling, cohesion for 
our benefit there so that we 

73
00:03:07,240 --> 00:03:10,720
understand, so that we can 
maintain, so that we can build. 

74
00:03:11,040 --> 00:03:13,400
That's what that's about. 
So for me, these are really old 

75
00:03:13,400 --> 00:03:16,400
ideas and more appropriately 
timeless ideas. 

76
00:03:16,400 --> 00:03:18,080
They don't go away. 
We should be building on them, 

77
00:03:18,080 --> 00:03:21,360
not trying to muddle a message. 
Therefore, paying attention to 

78
00:03:21,360 --> 00:03:24,240
this stuff is important and I 
think that's what a lot of 

79
00:03:24,240 --> 00:03:26,360
people are trying to do when 
they reiterate or try and 

80
00:03:26,360 --> 00:03:28,960
reframe these, they're trying to
get that message out. 

81
00:03:29,640 --> 00:03:32,640
But then there are other things 
that I think we haven't paid 

82
00:03:32,640 --> 00:03:36,520
attention to Co quality. 
So these days the popular way of

83
00:03:36,520 --> 00:03:39,360
framing things in terms of 
issues of Co quality is in terms

84
00:03:39,360 --> 00:03:41,800
of technical debt. 
Now that's not really quite 

85
00:03:41,800 --> 00:03:45,760
right, but it's not a bad 
metaphor, although we do misuse 

86
00:03:45,760 --> 00:03:48,440
it a little bit. 
But if you look back at the 

87
00:03:48,440 --> 00:03:51,680
past, people have been talking 
about Co quality issues forever 

88
00:03:51,840 --> 00:03:53,360
since they realized there was an
issue. 

89
00:03:53,720 --> 00:03:56,320
One of the things we've learned 
is that this really does make a 

90
00:03:56,320 --> 00:03:58,600
difference to the future of 
development. 

91
00:03:59,080 --> 00:04:03,160
So how can we expect people to 
easily add things in future? 

92
00:04:03,440 --> 00:04:05,720
Put it another way, most 
developers are living in the 

93
00:04:05,720 --> 00:04:07,600
past. 
When somebody sits down in front

94
00:04:07,600 --> 00:04:10,520
of a piece of code, they are 
projecting themselves into the 

95
00:04:10,520 --> 00:04:12,200
past. 
Maybe it was the past them, 

96
00:04:12,200 --> 00:04:15,200
maybe it's past somebody else. 
But when people are working on a

97
00:04:15,200 --> 00:04:18,519
code base, they are spending, 
let's say, in an 8 hour day, 

98
00:04:18,519 --> 00:04:21,560
they are spending about 7 to 7 
1/2 hours dealing with the 

99
00:04:21,560 --> 00:04:24,400
problems of the past. 
Oh, I'm trying to add a feature.

100
00:04:24,560 --> 00:04:26,160
Yeah, I can see you're trying to
add a feature. 

101
00:04:26,160 --> 00:04:28,520
But actually what you're doing 
is you're grappling with the way

102
00:04:28,520 --> 00:04:30,720
that the code has evolved. 
You're actually fighting the 

103
00:04:30,720 --> 00:04:33,000
past because you know that you 
want this feature to be 

104
00:04:33,000 --> 00:04:34,800
different, but you don't 
understand the code that's 

105
00:04:34,800 --> 00:04:37,040
there. 
Or you're fixing a bug. 

106
00:04:37,040 --> 00:04:38,600
Fixing a bug is living in the 
past. 

107
00:04:38,720 --> 00:04:40,960
Trying to understand code that 
was written that's living in the

108
00:04:40,960 --> 00:04:44,800
past, working around something 
that's living in the past. 

109
00:04:45,240 --> 00:04:47,200
Writing a test for a piece of 
code that doesn't have a test 

110
00:04:47,200 --> 00:04:48,680
that's living in the past. 
In other words, these are all 

111
00:04:48,680 --> 00:04:50,280
things that should have been 
solved in the past. 

112
00:04:50,680 --> 00:04:52,800
People spend most of their time 
living in the past. 

113
00:04:52,800 --> 00:04:55,200
And I'm not saying that we don't
do that or shouldn't do that. 

114
00:04:55,200 --> 00:04:56,680
We're there's always going to be
some percentage. 

115
00:04:56,960 --> 00:04:59,360
But I think that actually 
defines most of what programmers

116
00:04:59,360 --> 00:05:01,760
do. 
Very few developers actually 

117
00:05:01,760 --> 00:05:05,240
spend their time genuinely 
adding value to code bases. 

118
00:05:05,280 --> 00:05:07,400
They spend their time 
compensating for the problems, 

119
00:05:07,400 --> 00:05:09,520
the past. 
And this is a distinction that 

120
00:05:09,520 --> 00:05:12,120
systems thinker John said and 
highlights as value demand 

121
00:05:12,120 --> 00:05:14,360
versus failure demand. 
The demand for your work. 

122
00:05:14,520 --> 00:05:16,920
How much of your work is 
actually spent on dealing with 

123
00:05:16,960 --> 00:05:20,200
problems that have arisen in the
past and more importantly for 

124
00:05:20,200 --> 00:05:22,800
me, problems that are actually 
solved problems. 

125
00:05:23,360 --> 00:05:25,440
So let me bring something more 
up to date. 

126
00:05:25,440 --> 00:05:28,880
So refactoring that I think for 
many people they just assume 

127
00:05:28,880 --> 00:05:31,680
that part of the software 
development landscape, actually 

128
00:05:31,680 --> 00:05:35,960
until the late 90s, that wasn't 
really a known term or a popular

129
00:05:35,960 --> 00:05:38,080
idea. 
In one sense, we've done really 

130
00:05:38,080 --> 00:05:40,800
well here. 
But if you go back and you look 

131
00:05:40,800 --> 00:05:44,480
at Martin Fowler's original book
on refactoring, or the original 

132
00:05:44,480 --> 00:05:47,080
writings and terms of Extreme 
Programming, which really 

133
00:05:47,080 --> 00:05:49,880
focused trying to bring 
refactoring as forward to the 

134
00:05:49,880 --> 00:05:52,960
front as it were. 
So refactoring in many people's 

135
00:05:52,960 --> 00:05:54,600
heads exists in one of two 
spaces. 

136
00:05:54,880 --> 00:05:57,440
Oh, refactoring. 
That's a big work we do on our 

137
00:05:57,440 --> 00:05:59,440
legacy code base. 
You know, refactoring is to do 

138
00:05:59,440 --> 00:06:01,680
with legacy, is to do with bad 
code. 

139
00:06:02,560 --> 00:06:04,080
And then the other one is, oh, 
refactoring. 

140
00:06:04,080 --> 00:06:06,680
Yeah, that's the shortcut key 
that gets me to rename things 

141
00:06:06,680 --> 00:06:09,640
and occasionally Extract method.
And it's just like actually 

142
00:06:09,640 --> 00:06:12,400
refactoring is a design practice
and it's not always about bad 

143
00:06:12,400 --> 00:06:14,760
code. 
Refactoring is the idea that 

144
00:06:14,760 --> 00:06:17,960
your software is supposed to be 
sought, and therefore when you 

145
00:06:17,960 --> 00:06:20,080
come up with a better 
understanding of something, you 

146
00:06:20,080 --> 00:06:21,720
oh, wait a minute, there's a 
better way of writing this. 

147
00:06:22,200 --> 00:06:25,160
I should be able to reshape it 
easily so that I reflect my 

148
00:06:25,160 --> 00:06:27,600
current thinking instead of 
using yesterday's thinking. 

149
00:06:27,600 --> 00:06:30,480
I've got my current thinking. 
I keep the code fresh. 

150
00:06:30,960 --> 00:06:34,520
Therefore it's constantly in the
state of improvement and 

151
00:06:34,520 --> 00:06:36,560
response. 
Because we're always operating 

152
00:06:36,560 --> 00:06:38,760
with incomplete knowledge. 
We can never know everything. 

153
00:06:39,080 --> 00:06:42,000
It also allows me to be more 
forgiving, if you like. 

154
00:06:42,200 --> 00:06:44,520
Yeah, we got that wrong, but now
we can make it right. 

155
00:06:44,560 --> 00:06:47,000
And that's not a big deal. 
That's part of what we call 

156
00:06:47,000 --> 00:06:49,040
software development. 
It's not a separate thing. 

157
00:06:49,240 --> 00:06:51,600
It's not a separate activity I 
have to ask somebody permission 

158
00:06:51,600 --> 00:06:53,640
for. 
It doesn't have that idea 

159
00:06:53,640 --> 00:06:55,400
though. 
It's just part of the flow. 

160
00:06:56,000 --> 00:06:59,040
And so I think that although you
open up a modern IDE, it's got 

161
00:06:59,040 --> 00:07:01,360
refactoring there. 
Most people don't use that apart

162
00:07:01,360 --> 00:07:03,480
from rename kind of have a 
standard Joe. 

163
00:07:03,480 --> 00:07:05,880
What I point out to people, it's
just like, isn't it great these 

164
00:07:05,880 --> 00:07:07,200
days? 
We don't have legacy code 

165
00:07:07,200 --> 00:07:09,360
because when I joined the 
industry, we had legacy code. 

166
00:07:09,880 --> 00:07:12,800
In fact, the term legacy was 
first used in 1989. 

167
00:07:12,840 --> 00:07:15,800
So the term legacy applied to 
code was actually the year that 

168
00:07:15,800 --> 00:07:18,360
I joined the industry. 
And I say, isn't it great these 

169
00:07:18,360 --> 00:07:20,560
days that we don't have legacy 
code because we've got the 

170
00:07:20,560 --> 00:07:23,040
refactoring tools that eliminate
most of all the problems, you 

171
00:07:23,040 --> 00:07:25,080
know, but people used to 
complain, oh, we've got this 

172
00:07:25,080 --> 00:07:27,320
method, it's too long. 
It's so good that we don't have 

173
00:07:27,320 --> 00:07:29,440
that problem anymore because we 
have ways of breaking up 

174
00:07:29,440 --> 00:07:31,240
methods. 
And people say, Oh yeah, classes

175
00:07:31,240 --> 00:07:32,600
that are too big. 
Again, we don't have those 

176
00:07:32,600 --> 00:07:34,160
problems because you can extract
class. 

177
00:07:34,480 --> 00:07:37,280
Eventually, kind of people get 
the idea that I am joking. 

178
00:07:37,440 --> 00:07:39,080
And actually I'm asking a deeper
question. 

179
00:07:39,120 --> 00:07:41,920
We have these tools. 
So why do we still have all of 

180
00:07:41,920 --> 00:07:44,160
the problems that these tools 
solve and what that actually 

181
00:07:44,160 --> 00:07:45,880
teaches us? 
It was not a tooling problem. 

182
00:07:46,280 --> 00:07:48,680
That's what it teaches us. 
We have given everybody 

183
00:07:48,680 --> 00:07:51,720
everything they need. 
So in other words, this is the 

184
00:07:51,720 --> 00:07:54,600
interesting thing. 
For most software, we know how 

185
00:07:54,600 --> 00:07:58,240
to deliver it with low defects, 
with low unmanaged technical 

186
00:07:58,240 --> 00:08:01,000
debt, and to deliver it close to
being on time. 

187
00:08:01,360 --> 00:08:04,000
These are solved problems. 
By the end of the 20th century. 

188
00:08:04,000 --> 00:08:07,560
Every single one of the problems
I've just mentioned was Sol, and

189
00:08:07,560 --> 00:08:10,680
yet we still struggle with them.
So for me, that's the bit of the

190
00:08:10,680 --> 00:08:12,600
past you want to live in. 
What are the good ideas? 

191
00:08:12,600 --> 00:08:14,640
We are still not applying 
consistently. 

192
00:08:14,960 --> 00:08:17,680
I still have to discuss with 
people whether or not they 

193
00:08:17,680 --> 00:08:19,520
should test. 
That shouldn't even be a 

194
00:08:19,520 --> 00:08:22,520
discussion. 
OK, you write tests if you can 

195
00:08:22,520 --> 00:08:25,040
get high statement coverage, 
well done. 

196
00:08:25,040 --> 00:08:27,560
There's other forms of coverage,
but that should be the minimum. 

197
00:08:27,760 --> 00:08:30,560
When people say, Oh yeah, we've 
got less, do you have 100% 

198
00:08:30,560 --> 00:08:33,600
statement coverage? 
No, no, we're at about 50%. 

199
00:08:33,600 --> 00:08:36,159
OK You do know that 100% 
statement coverage is really 

200
00:08:36,159 --> 00:08:38,000
easy to get and people are 
always shocked by that. 

201
00:08:38,000 --> 00:08:40,559
It's just like, well, yeah, you 
just do test driven development.

202
00:08:40,919 --> 00:08:43,320
That's it. 
People who do TDD don't worry 

203
00:08:43,320 --> 00:08:44,960
about coverage. 
Or rather, they worry about when

204
00:08:44,960 --> 00:08:47,560
the needle dips below 100 
because that normally means 

205
00:08:47,560 --> 00:08:49,880
there's some dead code. 
This statement coverage is only 

206
00:08:49,880 --> 00:08:52,120
interesting for people that 
don't do TDD or other forms of 

207
00:08:52,120 --> 00:08:54,320
continuous testing. 
The idea if you are doing 

208
00:08:54,320 --> 00:08:57,240
continuous testing, coverage is 
not interesting. 

209
00:08:57,400 --> 00:08:59,840
It's a figure that you always 
expect to be high because you're

210
00:08:59,840 --> 00:09:02,000
always writing your code and 
your test together. 

211
00:09:02,000 --> 00:09:04,400
Maybe you lead with the test TDD
style. 

212
00:09:04,560 --> 00:09:07,840
This is a solved problem. 
We solved this years ago, but 

213
00:09:07,840 --> 00:09:10,160
people still struggle with it. 
They try to justify having to 

214
00:09:10,160 --> 00:09:12,280
run tests. 
I was talking to somebody 

215
00:09:12,280 --> 00:09:14,760
yesterday from Microsoft about 
this whole thing about why is it

216
00:09:14,760 --> 00:09:18,040
that people are not using static
analysis and high warning levels

217
00:09:18,040 --> 00:09:20,400
more? 
There are reasons, but they're 

218
00:09:20,400 --> 00:09:22,520
not very good ones. 
Why do people not have clean 

219
00:09:22,520 --> 00:09:24,840
builds? 
Once you solve all of these, it 

220
00:09:24,840 --> 00:09:27,160
leaves you with the real 
problems that are interesting 

221
00:09:27,520 --> 00:09:30,240
once you've cleaned up the bad 
code, Once you've cleaned up all

222
00:09:30,240 --> 00:09:33,360
of this kind of stuff, you will 
still have legacy, but that 

223
00:09:33,360 --> 00:09:35,120
legacy will be there for a 
different reason. 

224
00:09:35,360 --> 00:09:38,280
That legacy will be leftover 
decisions from the past. 

225
00:09:38,280 --> 00:09:40,400
Your challenge is now to deal 
with like, yeah, we took this 

226
00:09:40,400 --> 00:09:43,440
decision, but the technology 
landscape or the requirements of

227
00:09:43,440 --> 00:09:46,200
MU. 
So that decision is no longer 

228
00:09:46,200 --> 00:09:47,840
appropriate. 
It's not a bad decision, it's 

229
00:09:47,840 --> 00:09:51,160
just doesn't fit the world any. 
And we wrote this code in good 

230
00:09:51,160 --> 00:09:53,840
faith, but now it's no longer 
right. 

231
00:09:53,960 --> 00:09:56,440
So we need a better fit for the 
code in the world. 

232
00:09:57,000 --> 00:09:58,640
So don't worry. 
Once we've solved all the 

233
00:09:58,640 --> 00:10:00,200
problems, there are still plenty
of problems. 

234
00:10:00,200 --> 00:10:03,000
But what I'm saying is that most
of the things that people have 

235
00:10:03,000 --> 00:10:06,240
said, hey, modularize your code,
use a coherent paradigm, have 

236
00:10:06,240 --> 00:10:08,160
less state mutability. 
That doesn't mean you have to go

237
00:10:08,160 --> 00:10:10,680
do functional programming. 
If you're in a functional 

238
00:10:10,680 --> 00:10:12,080
language, that's absolutely 
brilliant. 

239
00:10:12,080 --> 00:10:13,880
If you're in a language that 
really nudges you in that 

240
00:10:13,880 --> 00:10:16,800
direction, that's great. 
But even as somebody who's 

241
00:10:16,800 --> 00:10:20,280
worked in C and Fortran, I'm 
going to say you don't have to 

242
00:10:20,280 --> 00:10:23,880
have highly imperative code. 
That's never been a great idea, 

243
00:10:24,040 --> 00:10:26,720
and you're not forced into that.
There are simple techniques you 

244
00:10:26,720 --> 00:10:29,760
can deal with. 
Modular as you code use various 

245
00:10:29,760 --> 00:10:32,040
techniques. 
A class is a module in this 

246
00:10:32,040 --> 00:10:33,640
sense. 
It is a modular construct. 

247
00:10:33,640 --> 00:10:35,840
Any form of data abstraction is 
a modular construct. 

248
00:10:36,240 --> 00:10:38,600
Micro services and modular 
constructs at a larger scale. 

249
00:10:39,240 --> 00:10:41,520
But the idea is, if you think 
that micro services are going to

250
00:10:41,520 --> 00:10:44,200
solve your poor modularity in 
your code, they're not. 

251
00:10:44,480 --> 00:10:46,400
When everybody says, hey, we're 
doing micro services because 

252
00:10:46,400 --> 00:10:49,440
it's going to improve the 
structure of our code, well you 

253
00:10:49,440 --> 00:10:51,120
don't need micro services to do 
that. 

254
00:10:51,120 --> 00:10:54,480
Micro services solve a very 
specific problem related to 

255
00:10:54,480 --> 00:10:57,200
deployment and scaling. 
That's what they're really good 

256
00:10:57,200 --> 00:11:00,560
at. 
If we have had so many paradigms

257
00:11:00,920 --> 00:11:03,640
over the last few decades that 
are about how to organise your 

258
00:11:03,640 --> 00:11:07,240
code, you don't need any more. 
You've got every single tool. 

259
00:11:07,240 --> 00:11:09,400
And if you can't do it with 
that, then you should take a 

260
00:11:09,400 --> 00:11:12,360
step back, put the mouse down, 
step away from the keyboard and 

261
00:11:12,360 --> 00:11:13,880
go wait, what's really going on 
here? 

262
00:11:14,160 --> 00:11:16,840
What is it that we are missing 
as a team collectively to 

263
00:11:16,840 --> 00:11:20,200
reinforce these practices? 
So yeah, the past is an 

264
00:11:20,200 --> 00:11:22,120
interesting place. 
We get drawn back to our 

265
00:11:22,120 --> 00:11:24,280
mistakes in the past, but we 
fail to learn from our 

266
00:11:24,280 --> 00:11:26,240
successes. 
So that would be my general 

267
00:11:26,240 --> 00:11:29,440
advice on this one. 
Listening to your explanation is

268
00:11:29,440 --> 00:11:32,840
very fascinating because a lot 
of developers these days chase 

269
00:11:32,840 --> 00:11:34,280
this hype driven development, 
right? 

270
00:11:34,280 --> 00:11:37,880
Oh, there's the new cool 
technologies, new framework, new

271
00:11:37,880 --> 00:11:41,800
libraries, new paradigms like 
micro services, event driven and

272
00:11:41,800 --> 00:11:43,920
things like that. 
But if we look back to the past,

273
00:11:43,920 --> 00:11:46,440
there are probably so many 
theories that still stays 

274
00:11:46,440 --> 00:11:48,560
relevant. 
And in fact, I noticed some of 

275
00:11:48,560 --> 00:11:51,120
these thought leaders in the 
tech industry like Dave Farley, 

276
00:11:51,160 --> 00:11:54,400
Robert Martin, Uncle Bob. 
They wrote books titled like 

277
00:11:54,400 --> 00:11:56,600
Modern Software Engineering and 
Clean Craftsmanship. 

278
00:11:56,600 --> 00:11:59,160
But if you look at the things 
that they are advocating, 

279
00:11:59,280 --> 00:12:03,160
actually it comes from the past.
The same fundamental things that

280
00:12:03,160 --> 00:12:04,960
stays relevant even up until 
now. 

281
00:12:05,320 --> 00:12:07,920
So I think the key message here 
I want to emphasize is that for 

282
00:12:07,920 --> 00:12:10,600
developers, please go back to 
the fundamentals, don't always 

283
00:12:10,600 --> 00:12:13,920
chase the new shiny things. 
There are still things that we 

284
00:12:13,920 --> 00:12:16,680
can probably master to become a 
better developers. 

285
00:12:17,360 --> 00:12:19,000
Yeah. 
And I think the value is that 

286
00:12:19,000 --> 00:12:21,120
when you understand though, it 
gives you a more solid 

287
00:12:21,120 --> 00:12:23,240
foundation. 
And when something new and shiny

288
00:12:23,240 --> 00:12:26,600
does come along, you now have a 
more objective assessment. 

289
00:12:26,600 --> 00:12:29,120
You can separate out and go, OK,
yeah, this is building on 

290
00:12:29,120 --> 00:12:30,600
foundations. 
There's nothing new here. 

291
00:12:31,160 --> 00:12:33,480
And then you can look at the bit
that actually is shiny and go, 

292
00:12:33,480 --> 00:12:36,440
this is the value of this. 
Or you may say, wait a minute, 

293
00:12:36,560 --> 00:12:38,840
there is nothing shiny here. 
This is just repackaging the 

294
00:12:38,840 --> 00:12:41,880
past and also it's mistakes. 
So maybe let's not do this one. 

295
00:12:42,000 --> 00:12:43,920
It gives you a more objective 
sense. 

296
00:12:44,360 --> 00:12:46,880
Of course, most people in 
technology get into technology 

297
00:12:46,880 --> 00:12:48,560
because they like the excitement
of something. 

298
00:12:48,560 --> 00:12:51,480
So we have to kind of watch 
ourselves a little bit on this. 

299
00:12:51,680 --> 00:12:53,360
We are our own worst enemy at 
this one. 

300
00:12:54,200 --> 00:12:57,120
So one thing that I always find 
fascinating also because there 

301
00:12:57,120 --> 00:13:00,120
are tools that are built by 
developers that makes things 

302
00:13:00,120 --> 00:13:01,840
easier for us to. 
Churn out code. 

303
00:13:02,040 --> 00:13:05,480
But not necessarily comply with 
this cohesion or this coupling. 

304
00:13:05,520 --> 00:13:07,840
So think of it like the 
framework, software frameworks, 

305
00:13:07,840 --> 00:13:09,560
right? 
So I think that's also another 

306
00:13:09,560 --> 00:13:12,280
thing that is fascinating. 
Like we tend to one, shortcuts 

307
00:13:12,360 --> 00:13:16,200
deliver something faster, but 
not adhering to the good best 

308
00:13:16,200 --> 00:13:18,320
principles that software should 
be written in. 

309
00:13:18,840 --> 00:13:21,720
So Kavlyn, another thing that 
you're very popular in, it's 

310
00:13:21,720 --> 00:13:23,960
what people call Kavlyn Haney's 
screen, right? 

311
00:13:24,240 --> 00:13:26,320
You can see in Kavlyn Haney's 
Twitter. 

312
00:13:26,400 --> 00:13:28,960
Just look at what we call 
software failure. 

313
00:13:28,960 --> 00:13:31,080
And these are normally public 
software failure. 

314
00:13:31,320 --> 00:13:33,720
And people just send, you know, 
pictures of these software 

315
00:13:33,720 --> 00:13:36,920
failures to Kavlyn. 
So maybe the first thing is tell

316
00:13:36,920 --> 00:13:40,400
us what the story is all about. 
How come people actually send 

317
00:13:40,400 --> 00:13:43,400
all these things to you? 
So the story goes back a long 

318
00:13:43,400 --> 00:13:45,600
way. 
I used to take screenshots. 

319
00:13:45,600 --> 00:13:48,520
Whenever something crashed on my
machine, I'd take a screenshot 

320
00:13:48,520 --> 00:13:50,720
of it, and sometimes I would 
integrate it into a torque. 

321
00:13:51,040 --> 00:13:52,960
Then of course, phones have 
cameras. 

322
00:13:52,960 --> 00:13:55,400
So I started taking pictures of 
software failures in public 

323
00:13:55,400 --> 00:13:58,200
places, because software runs 
the world, but it doesn't always

324
00:13:58,200 --> 00:13:59,480
run it in the way that we wanted
to. 

325
00:13:59,480 --> 00:14:02,800
There's a lot of reboot screens 
and screens which trace very 

326
00:14:02,800 --> 00:14:05,440
elegantly the whole text stack 
that's just crashed. 

327
00:14:06,040 --> 00:14:07,640
I started taking photographs of 
these, and again, I'd 

328
00:14:07,640 --> 00:14:10,080
incorporate those into talks or 
I'd just kind of put them on my 

329
00:14:10,080 --> 00:14:12,640
screen when running a workshop. 
A good source of entertainment, 

330
00:14:12,640 --> 00:14:15,600
but also going back to this 
question of quality as something

331
00:14:15,600 --> 00:14:18,840
I've always had an interest. 
It's a reminder of, like, yeah, 

332
00:14:18,840 --> 00:14:20,920
in the tech space, we have a 
certain responsibility. 

333
00:14:21,200 --> 00:14:22,560
We are creating things that 
crash. 

334
00:14:22,920 --> 00:14:24,320
We are creating things that 
don't work. 

335
00:14:24,640 --> 00:14:26,760
A bug isn't personal 
inconvenience to you or a 

336
00:14:26,760 --> 00:14:29,240
configuration issue is a 
personal inconvenience to you, 

337
00:14:29,520 --> 00:14:32,320
or it just becomes a ticket. 
The thing is to realize that it 

338
00:14:32,320 --> 00:14:34,760
exists in the world. 
It's not an abstraction. 

339
00:14:35,080 --> 00:14:36,160
It's actually exists in the 
world. 

340
00:14:36,320 --> 00:14:38,840
It's amusing sometimes, but also
it's probably preventing 

341
00:14:38,840 --> 00:14:40,680
somebody else being able to do 
something. 

342
00:14:41,240 --> 00:14:45,480
So I kind of highlighted these. 
Then as a result of this, people

343
00:14:45,480 --> 00:14:47,800
would then start emailing me 
these things. 

344
00:14:48,080 --> 00:14:49,440
Then we hit the social media 
area. 

345
00:14:49,560 --> 00:14:51,640
So it's much easier. 
They have to e-mail me, they can

346
00:14:51,640 --> 00:14:54,080
just tag me. 
So this was becoming a popular 

347
00:14:54,080 --> 00:14:56,920
thing on Twitter in particular. 
What I would do, because that's 

348
00:14:56,920 --> 00:15:00,560
a very public space, is that I 
would just retweet these. 

349
00:15:01,200 --> 00:15:04,560
Then people started making a 
point of doing this. 

350
00:15:04,600 --> 00:15:07,760
And in 2016, somebody actually 
started saying, oh, a kevlan 

351
00:15:07,760 --> 00:15:10,760
Henny screen because it had 
reached a particular point. 

352
00:15:11,120 --> 00:15:13,720
And so that's how my name got 
associated with it. 

353
00:15:13,720 --> 00:15:16,480
From that point, there's even 
somebody put an entry in Urban 

354
00:15:16,480 --> 00:15:19,480
Dictionary and there's even a 
mention in the register of this 

355
00:15:19,480 --> 00:15:20,960
stuff. 
So that's kind of an interesting

356
00:15:20,960 --> 00:15:23,280
thing. 
I was also asked by somebody 

357
00:15:23,440 --> 00:15:25,280
Kevlan, what does it feel like 
to have your name associated 

358
00:15:25,280 --> 00:15:27,040
with failure. 
So I think it's an interesting 

359
00:15:27,040 --> 00:15:29,480
way of looking at it. 
It's just like, yeah, I don't 

360
00:15:29,480 --> 00:15:32,200
'cause these screens, but it is 
interesting because it's a 

361
00:15:32,200 --> 00:15:35,760
reminder for me that, you know, 
when we deal with software, when

362
00:15:35,760 --> 00:15:38,720
we develop it, and when we 
deploy it, we are part of a 

363
00:15:38,720 --> 00:15:44,240
larger system where our failures
in software are no longer about 

364
00:15:44,240 --> 00:15:45,960
us. 
They are about other people. 

365
00:15:45,960 --> 00:15:48,240
They become very visible. 
And in a world that runs on 

366
00:15:48,240 --> 00:15:50,080
software, that becomes a 
prominent point. 

367
00:15:50,360 --> 00:15:52,880
Some of them are quite revealing
in a way that you don't want to 

368
00:15:52,880 --> 00:15:54,560
be revealing. 
Like I said, sometimes you get a

369
00:15:54,560 --> 00:15:57,160
complete stack trace. 
In fact, I saw one yesterday 

370
00:15:57,160 --> 00:15:59,960
which was quite interesting. 
The stack trace was not visible 

371
00:16:00,120 --> 00:16:03,200
even though there was an error. 
Because whoever created this had

372
00:16:03,200 --> 00:16:06,640
the wisdom to say, you know 
what, we're showing our internal

373
00:16:06,640 --> 00:16:10,160
structure that can be used 
against us from a security point

374
00:16:10,160 --> 00:16:11,520
of view. 
You discover that somebody's 

375
00:16:11,520 --> 00:16:13,840
using an unpatched version of 
something, you go, Oh yeah, 

376
00:16:13,840 --> 00:16:15,560
that's interesting. 
I've got a new attack vector 

377
00:16:15,560 --> 00:16:17,280
there. 
But it also tells us something 

378
00:16:17,280 --> 00:16:18,800
about the organisations that run
them. 

379
00:16:18,800 --> 00:16:22,720
I still get images of Windows XP
boot screens and failure 

380
00:16:22,720 --> 00:16:24,760
screens. 
Windows XP has been out of 

381
00:16:24,760 --> 00:16:28,160
support for a very long time. 
Again, we're living in the past.

382
00:16:28,160 --> 00:16:31,120
A lot of the world is running on
stuff that everybody thinks they

383
00:16:31,120 --> 00:16:33,720
left behind, but there isn't it 
actually all there. 

384
00:16:34,000 --> 00:16:36,600
We have a responsibility there 
that we need to get a little 

385
00:16:36,600 --> 00:16:40,200
better at this, but then we also
get the obvious programmer level

386
00:16:40,200 --> 00:16:41,800
bugs. 
It's just like, yeah, we should 

387
00:16:41,800 --> 00:16:44,160
have perhaps configured that a 
little more carefully or tested 

388
00:16:44,160 --> 00:16:46,680
that more thoroughly. 
It tells us about us. 

389
00:16:46,680 --> 00:16:48,200
That's what a lot of these 
things do. 

390
00:16:48,680 --> 00:16:51,320
But what is also interesting is 
that sometimes when people tag 

391
00:16:51,320 --> 00:16:54,360
me, particularly with something 
like public transport, they will

392
00:16:54,360 --> 00:16:56,000
also tag the public transport 
company. 

393
00:16:56,520 --> 00:16:58,960
And some of the time the public 
transport whoever's on Twitter 

394
00:16:58,960 --> 00:17:01,520
at that point will sort of say, 
Oh yeah, sorry about this, or 

395
00:17:01,520 --> 00:17:03,280
yes, we saw this problem. 
It's been resolved. 

396
00:17:03,320 --> 00:17:05,800
Or please tell us more because, 
you know, this is embarrassing 

397
00:17:05,800 --> 00:17:07,800
for us. 
So it's also a public service at

398
00:17:07,880 --> 00:17:10,520
that level? 
I hope you all the programmers 

399
00:17:10,520 --> 00:17:13,520
who build systems, never had a 
chance for your systems to be 

400
00:17:13,520 --> 00:17:15,440
sent to Kevin Haney for. 
Failures. 

401
00:17:15,760 --> 00:17:18,480
But I think the story that you 
just told, right, I think 

402
00:17:18,480 --> 00:17:20,599
there's a lot of things here 
that are insights. 

403
00:17:21,040 --> 00:17:24,079
So when you deploy software, 
especially for public systems 

404
00:17:24,079 --> 00:17:27,119
like public transport, airports,
sometimes I see all elevator. 

405
00:17:27,520 --> 00:17:29,320
So there are a lot of 
responsibilities. 

406
00:17:29,520 --> 00:17:31,960
Software failure can impact a 
lot of people. 

407
00:17:32,320 --> 00:17:34,400
These kind of things are 
definitely for one thing is 

408
00:17:34,400 --> 00:17:36,960
funny, yes, but at the other end
it's something for us to ponder 

409
00:17:36,960 --> 00:17:39,840
about software failures to be 
treated more seriously. 

410
00:17:42,240 --> 00:17:44,840
I hope you enjoyed this short 
clip from Technically Journal 

411
00:17:44,840 --> 00:17:47,720
Favorite Playlist. 
If you find this episode useful,

412
00:17:47,960 --> 00:17:50,640
please help share it with your 
friends and colleagues who you 

413
00:17:50,640 --> 00:17:53,360
think would also benefit from 
listening to this episode. 

414
00:17:53,840 --> 00:17:57,160
And if you want to listen more 
from this conversation, please 

415
00:17:57,160 --> 00:18:00,200
go back and listen to the 
original full conversation with 

416
00:18:00,200 --> 00:18:02,680
my guests. 
Stay tuned for the next Techly 

417
00:18:02,680 --> 00:18:05,320
Journal episode, and until then,
goodbye.