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

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

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

4
00:00:11,000 --> 00:00:13,300
appreciate it. 
If you can take a quick, pause 

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

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

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

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

9
00:00:24,800 --> 00:00:27,500
We want to write as little 
software as possible, and we 

10
00:00:27,500 --> 00:00:29,600
wanted to have as much value as 
possible. 

11
00:00:30,000 --> 00:00:33,500
I think that's an obvious thing.
But if you actually focus on 

12
00:00:33,500 --> 00:00:36,300
that, then you think a lot more 
about, how can I build that 

13
00:00:36,600 --> 00:00:38,100
other kind of build that 
quickly? 

14
00:00:38,300 --> 00:00:40,400
How can I have it maintainable 
when you evolve? 

15
00:00:40,400 --> 00:00:43,600
And how can I try and focus on 
the things that are maximum 

16
00:00:43,600 --> 00:00:46,900
value versus often? 
A project gets into all sorts of

17
00:00:46,900 --> 00:00:49,700
features and other stuff which 
really doesn't matter. 

18
00:00:49,700 --> 00:00:51,900
So, it means that you have to be
close to your customer. 

19
00:00:57,000 --> 00:00:59,800
Hey, everyone. 
My name is Henry Surya Widow. 

20
00:01:01,800 --> 00:01:04,700
And you're listening to the 
technology, you know, podcast 

21
00:01:05,099 --> 00:01:07,400
the show where I'll be bringing 
you the greatest technical 

22
00:01:07,400 --> 00:01:11,300
leaders practitioners and 
thought leaders in the industry 

23
00:01:11,600 --> 00:01:16,000
to discuss about their Journey 
ideas and practices that we all 

24
00:01:16,000 --> 00:01:19,600
can learn and apply to build a 
highly performing technical team

25
00:01:20,000 --> 00:01:22,400
and to make an impact in your 
personal work. 

26
00:01:22,900 --> 00:01:30,500
So let's dive into our Journal. 
Hello, to all of you. 

27
00:01:30,500 --> 00:01:33,600
My friends and my list. - 
welcome to the technology on our

28
00:01:33,600 --> 00:01:36,800
podcast, the show where you can 
learn about technical leadership

29
00:01:36,800 --> 00:01:39,500
and Excellence from my 
conversations, with great 

30
00:01:39,500 --> 00:01:42,800
thought, leaders out there. 
And this is the episode number 

31
00:01:42,800 --> 00:01:45,000
93. 
Thanks for tuning in and 

32
00:01:45,000 --> 00:01:47,800
listening to this episode. 
If this is your first time 

33
00:01:47,800 --> 00:01:50,800
listening to technology, you 
know, don't forget to subscribe 

34
00:01:50,800 --> 00:01:54,500
and follow the show on your 
podcast app and social media on 

35
00:01:54,500 --> 00:01:56,100
LinkedIn, Twitter, and 
Instagram. 

36
00:01:56,500 --> 00:01:59,800
And for those of you who enjoy 
this podcast and wanting to 

37
00:01:59,800 --> 00:02:03,600
contribute to the creation of 
the Our episodes support me by 

38
00:02:03,600 --> 00:02:06,900
subscribing as a patron at 
technology, not Dev slash 

39
00:02:06,900 --> 00:02:10,100
Patron. 
My guest for today's episode is 

40
00:02:10,100 --> 00:02:13,800
Dave, Thomas, Dave is the 
chairman of the dura Corp 

41
00:02:13,900 --> 00:02:17,700
founder of your Australia and 
Lambda gem conferences and a go 

42
00:02:17,700 --> 00:02:20,500
to conference fellow in this 
episode. 

43
00:02:20,500 --> 00:02:23,500
They've shared about his 
personal research, which he 

44
00:02:23,500 --> 00:02:28,200
currently refers as 42d on ideas
that we can use to develop high 

45
00:02:28,200 --> 00:02:31,800
value software rapidly. 
He started by describing Being 

46
00:02:31,800 --> 00:02:34,700
the current developers 
productivity challenges and 

47
00:02:34,700 --> 00:02:37,600
touch on. 
The idea that big is not better 

48
00:02:38,100 --> 00:02:41,600
relating to the size of the team
and code base and how he finds 

49
00:02:41,600 --> 00:02:43,900
the development tools are 
becoming more and more 

50
00:02:43,900 --> 00:02:47,400
complicated and complex. 
We then discussed on the 

51
00:02:47,400 --> 00:02:50,400
importance of developers, 
understanding domain, knowledge 

52
00:02:50,700 --> 00:02:53,300
leveraging tools, such as 
decision tables and 

53
00:02:53,300 --> 00:02:56,600
spreadsheets, and we also 
discussed how the choice of 

54
00:02:56,600 --> 00:03:00,700
programming language actually 
matters, who has the end they've

55
00:03:00,700 --> 00:03:03,900
shared about Using a data 
Centric approach to deal and 

56
00:03:03,900 --> 00:03:08,200
build upon Legacy systems 
towards the end they've shared 

57
00:03:08,200 --> 00:03:11,500
about using a data Centric 
approach to deal and build upon 

58
00:03:11,500 --> 00:03:14,500
Legacy systems. 
And also shared his perspective 

59
00:03:14,500 --> 00:03:17,000
on query as the future of 
programming. 

60
00:03:17,600 --> 00:03:19,700
I enjoyed my conversation with 
Dave. 

61
00:03:20,000 --> 00:03:22,900
As always he shares very 
insightful perspectives 

62
00:03:23,100 --> 00:03:25,700
especially taken from his vast 
experience. 

63
00:03:26,100 --> 00:03:28,400
And I'm always amazed by the 
different exotic. 

64
00:03:28,400 --> 00:03:32,100
Programming languages that he 
talks about if you So enjoyed 

65
00:03:32,100 --> 00:03:34,800
this episode, please share it 
with your friends and colleagues

66
00:03:35,000 --> 00:03:37,900
who can also benefit from 
listening to this episode. 

67
00:03:38,600 --> 00:03:41,700
Leave a rating and review on 
your podcast app and share your 

68
00:03:41,700 --> 00:03:44,800
comments or feedback about this 
episode on social media. 

69
00:03:45,100 --> 00:03:48,300
It is my ultimate mission to 
make this podcast available to 

70
00:03:48,300 --> 00:03:50,700
more people. 
And I need your help to support 

71
00:03:50,700 --> 00:03:52,500
me towards fulfilling my 
mission. 

72
00:03:53,000 --> 00:03:55,000
Before we continue to the 
conversation. 

73
00:03:55,200 --> 00:03:57,300
Let's hear some words from our 
sponsor. 

74
00:03:57,600 --> 00:04:00,900
Today's episode is proudly 
sponsored by skills matter. 

75
00:04:01,200 --> 00:04:03,400
The Mobile community and events 
platform. 

76
00:04:03,400 --> 00:04:07,800
With more than 100,000 software 
professionals here members. 

77
00:04:07,800 --> 00:04:10,400
Can organize their learning 
experiences around the 

78
00:04:10,400 --> 00:04:13,500
technology topics. 
They care about most you get 

79
00:04:13,500 --> 00:04:17,100
on-demand access to their latest
content thought, leadership 

80
00:04:17,100 --> 00:04:20,700
insights, as well as the 
exciting schedule of tech events

81
00:04:20,700 --> 00:04:24,600
running across all time zones. 
So we're the devops our data 

82
00:04:24,600 --> 00:04:28,600
science is your bus or you are a
fan of functional programming or

83
00:04:28,600 --> 00:04:32,200
all things Cloud, you can make 
real connections with People who

84
00:04:32,200 --> 00:04:36,300
share your interests head on 
over to skills method or come to

85
00:04:36,308 --> 00:04:39,200
become part of the tech 
community that matters most to 

86
00:04:39,200 --> 00:04:41,300
you. 
It's free to join and you will 

87
00:04:41,300 --> 00:04:44,400
find it easy to keep up with the
latest tech Trends. 

88
00:04:44,700 --> 00:04:47,400
Are you looking for a new cool 
swag package? 

89
00:04:47,400 --> 00:04:50,300
You know now offers you some 
swags that you can purchase 

90
00:04:50,300 --> 00:04:54,800
online these wax are printed on 
demand based on your preference 

91
00:04:55,000 --> 00:04:58,000
and will be delivered safely to 
you all over the world where 

92
00:04:58,000 --> 00:05:01,100
shipping is available. 
Check out all the cool tracks 

93
00:05:01,100 --> 00:05:03,100
available. 
Bill by visiting technology, no 

94
00:05:03,100 --> 00:05:06,300
dot f / shop, and don't forget 
to break yourself. 

95
00:05:06,400 --> 00:05:12,100
Once you receive any of those 
threats, hello everyone. 

96
00:05:12,100 --> 00:05:15,100
Welcome back to the new episode 
of the pycnogenol podcast. 

97
00:05:15,200 --> 00:05:18,400
Today, I have someone with me 
who I always admired, whenever 

98
00:05:18,400 --> 00:05:22,000
he gave presentations or talks 
when he came by to Singapore, 

99
00:05:22,400 --> 00:05:26,100
his name is Dave Thomas, he is 
also, the founder of eaeu 

100
00:05:26,100 --> 00:05:28,200
Australia. 
And also the go to conference 

101
00:05:28,200 --> 00:05:30,100
fellow. 
I always find your top very 

102
00:05:30,100 --> 00:05:33,500
insightful, so, Looking forward 
to this conversation, Dave and 

103
00:05:33,500 --> 00:05:35,700
I'm very pleased to have this 
chance to talk to you today. 

104
00:05:37,100 --> 00:05:39,900
Henry, thanks very much for a 
great show, really enjoy 

105
00:05:39,900 --> 00:05:42,100
listening to it and catching 
them online. 

106
00:05:42,400 --> 00:05:44,000
Yes, there are two, Dave Thomas 
has. 

107
00:05:44,000 --> 00:05:45,700
Fortunately, he's a very good 
friend. 

108
00:05:45,900 --> 00:05:49,000
He was doing Ruby and prior to 
that I was doing Small Talk, 

109
00:05:49,000 --> 00:05:51,600
which you could sort of, think 
of as the first Ruby, if you 

110
00:05:51,600 --> 00:05:53,800
want. 
So, Dave's now doing her lying 

111
00:05:53,800 --> 00:05:56,600
in JavaScript, I'm dabbling in 
Becker. 

112
00:05:56,600 --> 00:05:59,400
Functional programming is where 
I've been for the last little 

113
00:05:59,400 --> 00:06:03,300
while, so great to be here. 
So maybe for people who may not 

114
00:06:03,300 --> 00:06:06,300
know you yet, if you can 
introduce yourself spending a 

115
00:06:06,300 --> 00:06:08,200
few minutes. 
Still tell us your journey 

116
00:06:08,400 --> 00:06:10,900
telling us more about your 
highlights or any turning points

117
00:06:10,900 --> 00:06:14,500
in your career. 
Oh, Henry, has to be careful 

118
00:06:14,500 --> 00:06:17,200
asking a software fossil about 
their history. 

119
00:06:17,300 --> 00:06:20,500
I could put the entire audience 
to sleep been really fortunate 

120
00:06:20,500 --> 00:06:22,200
to work with a lot of amazing 
people. 

121
00:06:22,400 --> 00:06:25,300
I think that's one of the 
advantages of being early in the

122
00:06:25,300 --> 00:06:28,100
field is there weren't very many
books and the word that many 

123
00:06:28,100 --> 00:06:30,100
experts. 
So I think in many ways it was a

124
00:06:30,108 --> 00:06:32,900
lot easier to become an expert 
because you didn't actually have

125
00:06:32,900 --> 00:06:36,000
to know that much. 
So I was very fortunate to be 

126
00:06:36,000 --> 00:06:38,500
there. 
I was able to work my way 

127
00:06:38,500 --> 00:06:41,500
through college paying by 
programming helping these 

128
00:06:41,500 --> 00:06:44,100
students in business do their 
religious assignments. 

129
00:06:44,100 --> 00:06:46,700
So, they could go skiing, they 
would pay good money for that. 

130
00:06:46,700 --> 00:06:50,300
So, I was fortunate to work in a
number of areas, during work 

131
00:06:50,300 --> 00:06:52,100
terms, and that was really 
great. 

132
00:06:52,300 --> 00:06:55,000
And then after graduation, I was
lucky to get a job in the 

133
00:06:55,008 --> 00:06:57,800
computer center, computer 
center, probably would not be 

134
00:06:57,800 --> 00:07:00,700
the place of maybe some people 
would go look today but in the 

135
00:07:00,700 --> 00:07:03,500
early days I mean that's where 
simula was invented was the 

136
00:07:03,500 --> 00:07:05,600
Norwegian. 
Computer center was really the 

137
00:07:05,600 --> 00:07:07,700
place if you wanted. 
C programming. 

138
00:07:07,700 --> 00:07:09,500
Language is an operating 
systems. 

139
00:07:09,700 --> 00:07:11,600
That was really the only place 
you can see it. 

140
00:07:11,600 --> 00:07:13,900
You could get in that big 
computer room with all that air 

141
00:07:13,900 --> 00:07:16,200
conditioning and be there with 
the machine. 

142
00:07:16,500 --> 00:07:19,400
So it was really quite exciting.
So I ran the programming 

143
00:07:19,400 --> 00:07:23,000
languages group there and work 
with both, the Honeywell in 

144
00:07:23,000 --> 00:07:24,900
Xerox who were computer 
companies. 

145
00:07:24,900 --> 00:07:28,600
In those days, we were able to 
through our relationships. 

146
00:07:28,600 --> 00:07:32,000
Helping them end up getting some
contracts, develop the Pascal, 

147
00:07:32,000 --> 00:07:36,100
compiler and compiler tools and 
database refactoring. 

148
00:07:36,600 --> 00:07:38,500
Oh jeez. 
So we developed quite a good 

149
00:07:38,500 --> 00:07:41,300
relationship and those. 
Fortunately, I got to see a lot 

150
00:07:41,300 --> 00:07:44,400
of the US industry from the 
inside and how they manage 

151
00:07:44,400 --> 00:07:47,200
software projects are didn't 
manage software projects as the 

152
00:07:47,200 --> 00:07:49,800
case may be. 
So I was there for a good while 

153
00:07:49,800 --> 00:07:52,800
and then I went back to grad 
school, did you graduate work 

154
00:07:52,800 --> 00:07:56,200
and specialized in databases and
programming languages? 

155
00:07:56,400 --> 00:07:59,600
And just as I was finishing grad
school, the dean of the School 

156
00:07:59,600 --> 00:08:02,400
of Business came and he says, 
you've been teaching our 

157
00:08:02,400 --> 00:08:05,800
students for some time. 
We really have a terrible old 

158
00:08:05,800 --> 00:08:08,600
fashioned die. 
The program, would you come and 

159
00:08:08,600 --> 00:08:11,400
be a faculty member and 
redesigned the program? 

160
00:08:11,400 --> 00:08:14,700
So I was a privilege to do that.
I did a lot of teaching it's a 

161
00:08:14,707 --> 00:08:18,000
privilege to teach students. 
Keep you honest they asked those

162
00:08:18,000 --> 00:08:21,100
naive really hard questions 
which always great to have to 

163
00:08:21,100 --> 00:08:24,400
think about I've started there 
and soon after that the Carleton

164
00:08:24,400 --> 00:08:27,800
University here in Ottawa Canada
decided that they wanted to have

165
00:08:27,800 --> 00:08:31,300
a new school of computer science
and so I was invited to 

166
00:08:31,300 --> 00:08:34,500
participate in the founding of 
that school I ended up with a 

167
00:08:34,508 --> 00:08:37,100
cross appointment between 
business and In computer 

168
00:08:37,100 --> 00:08:39,500
science. 
My undergrad is in electrical 

169
00:08:39,500 --> 00:08:41,700
engineering, but that's the nice
thing about Computing. 

170
00:08:41,700 --> 00:08:44,400
You get to go to different 
disciplines work with people and

171
00:08:44,400 --> 00:08:48,000
biology and finance and so on. 
And that's where I was really 

172
00:08:48,000 --> 00:08:51,500
interested in office automation.
I came across this work called 

173
00:08:51,500 --> 00:08:54,600
the system for business. 
Automation that took me down a 

174
00:08:54,608 --> 00:08:57,800
very interesting path in two 
languages like scheme and 

175
00:08:57,800 --> 00:09:00,100
particularly Carl. 
Hewitt's actors which is kind of

176
00:09:00,108 --> 00:09:02,000
the inspiration of things like 
Acca. 

177
00:09:02,000 --> 00:09:05,400
And so on the route, they're 
commercially that led me fairly 

178
00:09:05,400 --> 00:09:08,600
quickly towards the Len called 
small talk and object 

179
00:09:08,600 --> 00:09:10,800
orientation. 
So I was really interested in 

180
00:09:10,800 --> 00:09:12,200
that. 
We actually built an 

181
00:09:12,200 --> 00:09:16,100
implementation of small talk 
from the byte magazine in 1980 

182
00:09:16,300 --> 00:09:19,400
implemented in a very exotic 
language called APL. 

183
00:09:19,600 --> 00:09:22,400
There'd be many cruel and 
unnatural acts on my journey. 

184
00:09:22,700 --> 00:09:26,100
I love exotic languages so 
friend of mine called me up who 

185
00:09:26,100 --> 00:09:28,800
was in my engineering class and 
said look I'm building this 

186
00:09:28,800 --> 00:09:31,400
hardware company but we don't 
know anything about software. 

187
00:09:31,600 --> 00:09:33,000
You've got to come and work with
me. 

188
00:09:33,200 --> 00:09:36,500
So, I took my sabbatical working
in a company that builds at 80. 

189
00:09:36,600 --> 00:09:40,700
A and 68,000 microcomputers. 
We built a network operating 

190
00:09:40,700 --> 00:09:44,200
system essentially like a 
network file Appliance to 

191
00:09:44,200 --> 00:09:47,100
attended. 
A first course by Brad Cox who 

192
00:09:47,100 --> 00:09:49,600
was a GE. 
Then he had a language called 

193
00:09:49,600 --> 00:09:53,400
oopsie which you would only know
today as objective-c. 

194
00:09:53,700 --> 00:09:56,000
So that was the beginning. 
It wasn't ready. 

195
00:09:56,000 --> 00:10:00,200
So we both our own language and 
compiled it to fourth or there's

196
00:10:00,200 --> 00:10:03,900
a very interesting language. 
Many of the tricks we use their 

197
00:10:04,000 --> 00:10:07,400
we actually use later in small 
talk and Jabba Building embedded

198
00:10:07,400 --> 00:10:10,400
systems, how to put things in 
ROM and Flash and deal with 

199
00:10:10,400 --> 00:10:12,800
garbage collection in really 
complex systems. 

200
00:10:13,000 --> 00:10:16,700
So after I worked at this 
company die for I went back to 

201
00:10:16,700 --> 00:10:19,300
UNI and I was really convinced 
that I've needed to work on the 

202
00:10:19,300 --> 00:10:21,300
real thing. 
I needed really find out about 

203
00:10:21,300 --> 00:10:22,800
objects. 
The only way to do that was 

204
00:10:22,800 --> 00:10:25,800
really to study Small Talk. 
Fortunately we were able to get 

205
00:10:25,800 --> 00:10:29,400
early small talks from Berkeley.
Dave Unger's work on sore. 

206
00:10:29,400 --> 00:10:33,000
Did you talk methods and from 
tektronix who at the time we're 

207
00:10:33,000 --> 00:10:36,200
building a, I work stations. 
We were fortunate to get our 

208
00:10:36,600 --> 00:10:40,100
search funded by the DND in 
Canada who were looking for a 

209
00:10:40,108 --> 00:10:43,600
way to build models of 
multiprocessor systems. 

210
00:10:43,600 --> 00:10:47,200
So they funded us to build actra
which is a multiprocessor, small

211
00:10:47,200 --> 00:10:49,400
talk system. 
They also funded every 

212
00:10:49,400 --> 00:10:51,700
developer, which is the easiest 
way to describe it. 

213
00:10:51,700 --> 00:10:56,600
Sort of a get for small talk 
done Circa 1986 that allowed 

214
00:10:56,600 --> 00:10:59,900
Small Talk programmers, who 
normally work in an image and 

215
00:10:59,900 --> 00:11:03,700
you do not cooperate to actually
share and do version management,

216
00:11:03,700 --> 00:11:06,500
fine-grained level and that was 
our first product. 

217
00:11:06,900 --> 00:11:10,700
Then both tektronix Cindy and 
defunded us to build a 

218
00:11:10,700 --> 00:11:13,000
production. 
Small talk, and the small talk 

219
00:11:13,000 --> 00:11:16,700
we built for tektronix embedded.
Small, Talk V was actually put 

220
00:11:16,700 --> 00:11:18,500
into the tektronix 
oscilloscopes. 

221
00:11:18,700 --> 00:11:22,600
And those oscilloscope started 
shipping in 1988 before Java 

222
00:11:22,600 --> 00:11:25,400
there were byte codes inside of 
embedded systems. 

223
00:11:25,700 --> 00:11:29,600
Several of them, including later
on the momenta pain computer and

224
00:11:29,600 --> 00:11:33,100
first version of the Sony 
Qualcomm mobile phone prototypes

225
00:11:33,100 --> 00:11:36,400
in the early 90s, so that was 
really exciting. 

226
00:11:36,500 --> 00:11:41,400
Small Talk was a wonderful time 
in 1997 oti which was the 

227
00:11:41,400 --> 00:11:44,600
company that did this work was 
purchased by IBM. 

228
00:11:44,900 --> 00:11:47,900
Of course, before that had built
IBM a small talk which was the 

229
00:11:47,900 --> 00:11:50,300
basis for the IBM, visualized 
platform. 

230
00:11:50,600 --> 00:11:53,500
After we were purchased, we were
given the mission to develop 

231
00:11:53,500 --> 00:11:57,300
visual aids for Java. 
And the IBM jvms known as j9. 

232
00:11:57,300 --> 00:12:00,800
Still to this day, we were 
headed the enjoyable and 

233
00:12:00,800 --> 00:12:03,200
challenging opportunity to 
develop that really without 

234
00:12:03,200 --> 00:12:07,000
access to the source code from 
sun because would be Needed. 

235
00:12:07,000 --> 00:12:09,900
So a lot of the core libraries 
and so on were actually written 

236
00:12:09,900 --> 00:12:13,400
from scratch whether j9 virtual 
machine and Ide. 

237
00:12:13,600 --> 00:12:17,000
At the time, we started with the
eclipse project Eclipse had 

238
00:12:17,000 --> 00:12:20,500
another part called the UVM 
Universal virtual machine which 

239
00:12:20,500 --> 00:12:22,400
was a multi-language virtual 
machine. 

240
00:12:22,700 --> 00:12:25,600
But unfortunately IBM decided 
that they were only going to go 

241
00:12:25,600 --> 00:12:29,000
ahead with Jabba at that point 
Eclipse was off and running but 

242
00:12:29,000 --> 00:12:31,900
it became only a Java IDE 
originally, it was designed to 

243
00:12:31,900 --> 00:12:36,000
be a multi-language ID, that's 
the way the journey goes I left.

244
00:12:36,000 --> 00:12:37,500
IBM. 
About that time. 

245
00:12:37,600 --> 00:12:40,200
At that point, everyone was 
getting quite excited about 

246
00:12:40,200 --> 00:12:44,300
something called XP and scrum. 
Fortunately, we had a protest at

247
00:12:44,300 --> 00:12:47,700
OT, I called Justin Time 
software, which was really very 

248
00:12:47,700 --> 00:12:51,300
much in the spirit of XP. 
I joined up with a bunch of 

249
00:12:51,300 --> 00:12:54,100
other enthusiasts to form, 
something called the agile 

250
00:12:54,100 --> 00:12:57,600
Alliance which I sort of 
apologize because agile has been

251
00:12:57,600 --> 00:13:00,500
such a depressing thing way. 
It's been implemented. 

252
00:13:00,600 --> 00:13:04,000
It seemed like such a good idea.
How could something, so simple, 

253
00:13:04,000 --> 00:13:06,400
go so wrong. 
Oh well my apologies. 

254
00:13:07,100 --> 00:13:09,000
Objects. 
Do had their problems, dude. 

255
00:13:09,000 --> 00:13:11,600
They're really powerful, but 
they're very stateful and you 

256
00:13:11,608 --> 00:13:14,900
can make things complicated, 
learn some lessons from these 

257
00:13:14,900 --> 00:13:17,400
things. 
After that did a lot of training

258
00:13:17,400 --> 00:13:19,900
and transitioning to people to 
0. 

259
00:13:19,900 --> 00:13:23,300
And then I had to withdraw 
myself and go back to a place 

260
00:13:23,300 --> 00:13:27,100
called Madera research Labs with
my former partner from oti Bryan

261
00:13:27,100 --> 00:13:30,700
Berry focus on Research or 
research themes were 

262
00:13:30,700 --> 00:13:33,800
collaborative, analytics. 
Accelerated, development and 

263
00:13:33,800 --> 00:13:36,800
embedded systems. 
We did one project and Bedded 

264
00:13:36,800 --> 00:13:39,200
systems and then Canadian 
government agency. 

265
00:13:39,200 --> 00:13:41,500
CSE came along and said we have 
this. 

266
00:13:41,500 --> 00:13:43,400
Big problem with cyber 
analytics. 

267
00:13:43,600 --> 00:13:45,300
We're using these really old 
tools. 

268
00:13:45,300 --> 00:13:48,700
We can't keep up with the data 
volumes in the speed so they 

269
00:13:48,700 --> 00:13:51,200
said, we'll punch you to try 
your next crazy thing. 

270
00:13:51,200 --> 00:13:53,500
They'd already use small talk 
and Eclipse IDE. 

271
00:13:53,500 --> 00:13:56,600
Done in the past will try, 
whatever you're doing this time.

272
00:13:56,900 --> 00:13:59,900
Very fortunate to have these 
kinds of customers, so we built 

273
00:13:59,900 --> 00:14:03,300
something we called IV which is 
essentially a visual workbench 

274
00:14:03,300 --> 00:14:06,400
for collaborative analytics. 
We sold that to a company called

275
00:14:06,600 --> 00:14:09,500
First derivatives created KX 
Labs. 

276
00:14:09,500 --> 00:14:13,100
I was a chief scientist there 
until a couple of years ago when

277
00:14:13,100 --> 00:14:16,000
the last 18 months, what I've 
been doing is fortunately 

278
00:14:16,000 --> 00:14:18,600
through Zoom interacting with 
the bunch of interesting people 

279
00:14:18,600 --> 00:14:21,500
around the world, which is, I 
think the good news about the 

280
00:14:21,500 --> 00:14:24,200
pandemic. 
I've started my own personal 

281
00:14:24,200 --> 00:14:27,800
research Journey, now that I 
have time to go back and look at

282
00:14:27,800 --> 00:14:31,300
some of the things that I found,
very interesting but didn't have

283
00:14:31,300 --> 00:14:35,300
time to polish really understand
what was good or bad about them.

284
00:14:35,600 --> 00:14:37,900
I'm now able to do that to 
leisurely Pace. 

285
00:14:38,000 --> 00:14:41,200
I'm sure it'll keep me busy for 
the remaining time than I'm able

286
00:14:41,200 --> 00:14:44,600
to use my technical brain. 
Thank you for sharing such a 

287
00:14:44,600 --> 00:14:48,000
comprehensive journey of yours. 
So every time I listen to your 

288
00:14:48,000 --> 00:14:50,600
story, you did this in your 
talks as well, right? 

289
00:14:50,700 --> 00:14:53,500
So I'm always fascinated. 
I didn't know many of those 

290
00:14:53,500 --> 00:14:56,300
names that you've mentioned, 
maybe also because due to my 

291
00:14:56,300 --> 00:14:58,800
age, but always excited to hear.
Okay? 

292
00:14:58,800 --> 00:15:01,600
What are these things that Dave 
is talking about, seems like 

293
00:15:01,600 --> 00:15:05,100
very exotic very fascinating. 
And then your story also told a 

294
00:15:05,108 --> 00:15:09,400
lot of pin lines across Grabbing
languages object-oriented a gel 

295
00:15:09,400 --> 00:15:11,600
data. 
Today we are going to talk, 

296
00:15:11,600 --> 00:15:14,300
maybe a personal project of 
yours as well as part of your 

297
00:15:14,300 --> 00:15:17,000
personal research, which is 
called 42d. 

298
00:15:17,200 --> 00:15:19,400
Maybe name sounds interesting as
well. 

299
00:15:19,400 --> 00:15:21,600
Quite exotic. 
Can you tell us a little bit 

300
00:15:21,600 --> 00:15:23,800
more? 
What is this 42d project? 

301
00:15:24,300 --> 00:15:28,800
Sure. 42d is really just a 
personal project, 42 of course. 

302
00:15:28,800 --> 00:15:31,800
Everyone should know, is the 
answer to life and the meaning 

303
00:15:31,800 --> 00:15:34,800
of the universe. 
So, 42 D is just one small 

304
00:15:34,800 --> 00:15:38,600
Galaxy and it's the Alex see 
where we're seeking to explore 

305
00:15:38,600 --> 00:15:41,800
and find ways so that small 
groups of developers can develop

306
00:15:41,800 --> 00:15:45,300
high-value software quickly 
that's really been my interest. 

307
00:15:45,300 --> 00:15:49,700
Every time start a new product, 
a new application, is there some

308
00:15:49,700 --> 00:15:53,000
way we can change the process, 
change the tooling change, how 

309
00:15:53,000 --> 00:15:57,300
we think, such that we can be 
more productive and not end up 

310
00:15:57,300 --> 00:15:59,300
with big ugly code Mountain 
that. 

311
00:15:59,300 --> 00:16:02,800
We always seem to end up with 
that's what 42d is about and 

312
00:16:02,800 --> 00:16:05,700
it's really just taking a few 
things that I found to be 

313
00:16:05,800 --> 00:16:08,800
really. 
Full overtime, trying to now 

314
00:16:08,800 --> 00:16:12,000
think about them and see if I 
can bring them to more mature 

315
00:16:12,000 --> 00:16:14,500
ideas. 
So for those of you who may not 

316
00:16:14,500 --> 00:16:16,900
know about the meaning of life 
and all that, I think Dave, is 

317
00:16:16,900 --> 00:16:19,500
referring to this Hitchhiker's 
Guide to the Galaxy. 

318
00:16:19,700 --> 00:16:22,700
This term comes from there so 
you're talking about increasing 

319
00:16:22,700 --> 00:16:25,100
productivity. 
Is it still the case that 

320
00:16:25,100 --> 00:16:27,200
developer is still not 
productive? 

321
00:16:27,300 --> 00:16:30,500
I mean, technology has advanced 
rapidly, so many tools, so many 

322
00:16:30,500 --> 00:16:33,000
advancements, a IML and all 
that. 

323
00:16:33,200 --> 00:16:36,300
So maybe if you can elaborate a 
little bit more, why do you 

324
00:16:36,300 --> 00:16:38,300
think think developers 
productivity is still a 

325
00:16:38,300 --> 00:16:41,300
challenge these days? 
I think because they're just too

326
00:16:41,300 --> 00:16:44,400
much stuff vendors and Capi 
Field of Dreams. 

327
00:16:44,600 --> 00:16:49,000
Every you name it the next 
Amazon or Google Cloud, they all

328
00:16:49,000 --> 00:16:52,300
introduce another 40 or 50 apis.
They'll sort them 

329
00:16:52,300 --> 00:16:54,700
alphabetically. 
So they're easy to use, there's 

330
00:16:54,700 --> 00:16:56,700
many cases, they do the same 
thing. 

331
00:16:57,100 --> 00:16:59,500
So you can't even tell, which 
one should I choose? 

332
00:16:59,900 --> 00:17:02,100
The problem is this, there's so 
much of this stuff. 

333
00:17:02,200 --> 00:17:05,000
There's so many libraries. 
There's so many open source, 

334
00:17:05,000 --> 00:17:08,500
tools, and so many. 
Tools is very hard and they're 

335
00:17:08,500 --> 00:17:11,800
constantly changing. 
So if you look people or oh no 

336
00:17:11,800 --> 00:17:14,099
I'm moving from this one to that
one. 

337
00:17:14,200 --> 00:17:17,300
Or I'm upgrading from this 
version to another so people are

338
00:17:17,300 --> 00:17:21,500
not using them, they're learning
the next one and so it's very 

339
00:17:21,500 --> 00:17:25,700
complicated API design. 
And framework design is really 

340
00:17:25,700 --> 00:17:29,100
language design. 
And language is on is very hard 

341
00:17:29,200 --> 00:17:32,800
when you're in a rush and you're
producing apis very quickly to 

342
00:17:32,800 --> 00:17:35,600
be competitive. 
You often don't get the same 

343
00:17:35,600 --> 00:17:38,000
thought. 
Imitation and examples. 

344
00:17:38,200 --> 00:17:41,300
So this means it poor developers
have to perform experiments 

345
00:17:41,600 --> 00:17:44,900
while a good news is lots of 
things to blog because now you 

346
00:17:44,900 --> 00:17:49,500
have to find how to use react 
14, and the plays version of go 

347
00:17:49,500 --> 00:17:51,900
and rust. 
These languages are actually 

348
00:17:51,900 --> 00:17:55,000
very nice Scotland's a much 
nicer simpler Jabba. 

349
00:17:55,300 --> 00:17:59,600
But the surface area of these 
apis keeps growing and it varies

350
00:17:59,600 --> 00:18:02,700
from vendor to vendor. 
So this makes things very 

351
00:18:02,700 --> 00:18:06,300
complicated though, thing. 
Is it my colleagues call me that

352
00:18:06,500 --> 00:18:09,700
In an asynchronous world and 
then we have to have everything 

353
00:18:09,700 --> 00:18:12,800
be fully asynchronous to scale 
and get performance. 

354
00:18:13,100 --> 00:18:17,000
This is definitely true. 
The bad news is asynchronous is 

355
00:18:17,000 --> 00:18:20,000
not something that most 
programmers are really good at. 

356
00:18:20,200 --> 00:18:24,300
There is a mechanism due to Eric
Marr called async/await, which 

357
00:18:24,300 --> 00:18:27,000
is heavily used. 
But there's a bunch of very 

358
00:18:27,000 --> 00:18:29,200
subtle State machines underneath
that. 

359
00:18:29,200 --> 00:18:31,200
You really want to understand 
what's going on. 

360
00:18:31,200 --> 00:18:33,700
You need to understand what 
these State machines are doing 

361
00:18:34,000 --> 00:18:37,100
asynchronous. 
Computing is still Challenge 

362
00:18:37,100 --> 00:18:38,900
versus, if you do something like
Fred. 

363
00:18:38,900 --> 00:18:42,700
George talks about very simple 
data flow before you knew about 

364
00:18:42,700 --> 00:18:45,300
it, there was a thing called 
data flow diagrams that we're 

365
00:18:45,300 --> 00:18:49,100
very easy to understand today. 
They were very easy to implement

366
00:18:49,100 --> 00:18:52,500
on micro service architecture, 
but when you start building, 

367
00:18:52,500 --> 00:18:55,900
these asynchronous systems are 
much more complicated. 

368
00:18:56,000 --> 00:18:59,700
So complicated tools, 
complicated designs and very 

369
00:18:59,700 --> 00:19:02,500
demanding requirements in terms 
of performance and scale. 

370
00:19:02,700 --> 00:19:04,600
That's why programming is harder
today. 

371
00:19:05,300 --> 00:19:07,800
I can see some of these And I'm 
just as well, especially for me 

372
00:19:07,800 --> 00:19:09,800
learning, new tools, learning 
new technologies. 

373
00:19:10,000 --> 00:19:12,400
You just finish one or two years
working on this technology and 

374
00:19:12,400 --> 00:19:13,800
then suddenly, oh, there's a new
one. 

375
00:19:13,800 --> 00:19:15,300
Okay. 
Maybe we should give it a try. 

376
00:19:15,500 --> 00:19:18,400
And the other Advantage is 
always, there's a new job for 

377
00:19:18,400 --> 00:19:20,500
these people. 
So you learn something new and 

378
00:19:20,500 --> 00:19:22,000
then you can jump to another 
job. 

379
00:19:22,200 --> 00:19:24,500
No, no, absolutely. 
I mean, it's great for resumes, 

380
00:19:24,500 --> 00:19:26,100
right? 
You just can't put that new 

381
00:19:26,100 --> 00:19:29,600
thing on the resume if you can 
run ahead and it's a serious 

382
00:19:29,600 --> 00:19:31,900
investment. 
So if you really learn it, I 

383
00:19:31,900 --> 00:19:34,500
mean everybody else has to learn
all those apis. 

384
00:19:34,600 --> 00:19:37,500
That's your 10,000 hours. 
You have to put in. 

385
00:19:38,000 --> 00:19:41,700
So you mentioned as a subtitle 
of this project for the 2D you 

386
00:19:41,700 --> 00:19:46,100
mentioned about maximum value 
and maximum speed, maybe you can

387
00:19:46,100 --> 00:19:47,900
explain what do you mean by 
maximum value? 

388
00:19:47,900 --> 00:19:51,500
Is it that the software that we 
build has the maximum value out 

389
00:19:51,500 --> 00:19:54,300
of it and maximum speed? 
Do you mean by the performance 

390
00:19:54,300 --> 00:19:57,100
of the software or is it that 
its speed of churning out that 

391
00:19:57,100 --> 00:20:00,500
software the speed has to do 
with the speed of development? 

392
00:20:00,600 --> 00:20:03,600
If it's high value software and 
it has to be passed and it needs

393
00:20:03,600 --> 00:20:06,800
to be passed to. 
It's really the value of the In 

394
00:20:06,800 --> 00:20:09,900
the sense that we want to write,
as little software as possible, 

395
00:20:09,900 --> 00:20:12,400
and we wanted to have as much 
value as possible. 

396
00:20:12,600 --> 00:20:16,200
I think that's an obvious thing,
but if you actually focus on 

397
00:20:16,200 --> 00:20:19,300
that, then you think a lot more 
about, how can I build that how 

398
00:20:19,300 --> 00:20:20,800
they can? 
I build that quickly? 

399
00:20:21,000 --> 00:20:23,100
How can I have it maintainable 
when evolve? 

400
00:20:23,100 --> 00:20:26,300
And how can I try and focus on 
the things that are maximum 

401
00:20:26,300 --> 00:20:29,600
value versus often? 
A project gets into all sorts of

402
00:20:29,600 --> 00:20:32,400
features and other stuff, which 
really doesn't matter. 

403
00:20:32,400 --> 00:20:34,600
So, it means that you have to be
close to your customer. 

404
00:20:35,000 --> 00:20:38,600
I think this is obvious Yes, but
if you talk to most Edge old 

405
00:20:38,600 --> 00:20:41,800
developers and you ask them what
the business value of the story 

406
00:20:41,800 --> 00:20:44,600
is they say, I don't know, it's 
just more important than this 

407
00:20:44,600 --> 00:20:46,600
other one. 
And they're buried in little 

408
00:20:46,600 --> 00:20:50,600
tiny stories because they don't 
really have the big picture that

409
00:20:50,600 --> 00:20:53,000
was really, when can't talk 
about the metaphor, he was 

410
00:20:53,000 --> 00:20:55,000
really talking about. 
Having the big picture of the 

411
00:20:55,000 --> 00:20:58,600
really big story in some sense 
because if you understand, the 

412
00:20:58,600 --> 00:21:01,500
key story, then that's where the
key value is. 

413
00:21:01,700 --> 00:21:04,900
And that's what you want to try 
and focus on an Implement, not 

414
00:21:04,900 --> 00:21:08,000
get distracted. 
And to all of Details and you 

415
00:21:08,000 --> 00:21:10,900
start with this problem, this 
challenge with many of the 

416
00:21:10,900 --> 00:21:14,400
software development teams is 
that you mentioned the speed 

417
00:21:14,400 --> 00:21:17,300
actually comes, if you form a 
team that is small enough, you 

418
00:21:17,300 --> 00:21:20,300
also mention right as little 
code as possible, bring as much 

419
00:21:20,300 --> 00:21:23,300
value as you can but the 
tendency these days is actually 

420
00:21:23,300 --> 00:21:26,700
to build more and more 
microservices, build more teams,

421
00:21:26,700 --> 00:21:29,300
add more people there. 
So many developers this day the 

422
00:21:29,300 --> 00:21:31,200
demands, right? 
So maybe you can tell us a 

423
00:21:31,208 --> 00:21:34,000
little bit more sometimes this 
is obvious, big is not better 

424
00:21:34,200 --> 00:21:36,200
but the tendency for us in this 
software. 

425
00:21:36,300 --> 00:21:38,900
Or will these days is just to 
crime and at more and more. 

426
00:21:39,600 --> 00:21:42,700
Oh I think you can go back to 
mythical man month where Fred 

427
00:21:42,700 --> 00:21:45,300
Brooks and also were bullet. 
This is the story of the 

428
00:21:45,300 --> 00:21:49,100
building, the IBM 360 computer 
is still a great book. 

429
00:21:49,200 --> 00:21:51,100
He points out that over and over
again. 

430
00:21:51,100 --> 00:21:54,400
We have this nice triangle about
resources and time. 

431
00:21:54,600 --> 00:21:57,700
Despite the fact that everyone 
who's ever worked in software, 

432
00:21:57,700 --> 00:22:01,400
says, yes, we need a smaller 
team because we can move quicker

433
00:22:01,500 --> 00:22:04,300
and we can focus. 
We can maintain quality 

434
00:22:04,600 --> 00:22:07,700
management has this panic. 
Because of everything rushing 

435
00:22:07,700 --> 00:22:11,800
along today and the fact that 
boober has 4000 developers and 

436
00:22:11,800 --> 00:22:14,900
maybe, you know, be only has 
thirty five hundred selenium 

437
00:22:14,900 --> 00:22:18,200
5,000 so they can have more than
doordash or whatever. 

438
00:22:18,500 --> 00:22:22,200
So there's just this desire to 
throw features out on this is 

439
00:22:22,200 --> 00:22:24,400
particularly true because of the
web culture. 

440
00:22:24,600 --> 00:22:28,800
So, web basing applications, 
people love to pile features in 

441
00:22:28,800 --> 00:22:30,600
them. 
The problem is that once you get

442
00:22:30,600 --> 00:22:34,000
this many developers, you've 
just got more and more people, 

443
00:22:34,000 --> 00:22:37,400
basically sticking code onto. 
Code mountain and it just 

444
00:22:37,400 --> 00:22:39,700
becomes a bigger and bigger 
mess. 

445
00:22:40,000 --> 00:22:43,100
Even though you've got tooling 
for testing and things like 

446
00:22:43,100 --> 00:22:44,000
that. 
In the end. 

447
00:22:44,000 --> 00:22:47,500
The only thing that matters is 
the code and went Code matters. 

448
00:22:47,500 --> 00:22:50,400
Then you get complexity. 
That's when you get technical 

449
00:22:50,400 --> 00:22:51,300
debt. 
Yeah. 

450
00:22:51,300 --> 00:22:53,700
Agile developers in the 
beginning, everything is great. 

451
00:22:53,700 --> 00:22:56,500
And then they start begging for 
technical debt cards, who 

452
00:22:56,500 --> 00:23:00,200
created the technical deck them,
because too many people running 

453
00:23:00,200 --> 00:23:02,600
too fast. 
The other thing is, if you have 

454
00:23:02,600 --> 00:23:05,800
to use a lot of different 
languages, a lot of different 

455
00:23:05,800 --> 00:23:08,700
tools, And you have to 
communicate between more teams 

456
00:23:08,700 --> 00:23:10,300
than you've got, all this 
overheads. 

457
00:23:10,500 --> 00:23:13,100
So you've got the Layton 
complexity plus The Accidental 

458
00:23:13,100 --> 00:23:16,400
complexity, like the apis are 
not working yet because it's a 

459
00:23:16,408 --> 00:23:21,400
brand new API from company XYZ. 
You just have more and more 

460
00:23:21,400 --> 00:23:24,700
people and just piles up. 
I'm not met anyone who has any 

461
00:23:24,700 --> 00:23:28,000
experience, who thinks that 
hiring a lot more people is the 

462
00:23:28,000 --> 00:23:31,700
answer for how to get better 
software but people do it. 

463
00:23:32,300 --> 00:23:34,400
The tendency from the industry 
is like that. 

464
00:23:34,400 --> 00:23:37,000
I'm looking at a start-up, so 
it's also So the same thing 

465
00:23:37,000 --> 00:23:39,700
hiring is always a challenge. 
We want to hire more and more. 

466
00:23:39,700 --> 00:23:42,500
We want to hire faster and we 
have a lot of competitors as 

467
00:23:42,500 --> 00:23:44,200
well. 
People also putting these kind 

468
00:23:44,200 --> 00:23:47,500
of people so it seems like what 
you're saying is resonating with

469
00:23:47,500 --> 00:23:50,100
me as well. 
Many developers now are being 

470
00:23:50,100 --> 00:23:52,700
demanded and there are more and 
more features and code are being

471
00:23:52,700 --> 00:23:54,400
written. 
Which brings us to the 

472
00:23:54,400 --> 00:23:57,200
discussion that you mentioned. 
More lines of code is actually 

473
00:23:57,200 --> 00:23:59,300
problematic. 
We have so many developers, 

474
00:23:59,300 --> 00:24:01,100
maybe they build more and more 
lines of code. 

475
00:24:01,300 --> 00:24:03,600
But why do you think bigger 
lines of code is always a 

476
00:24:03,600 --> 00:24:07,000
challenge, of course, maintain 
abilities one but Is the Tipping

477
00:24:07,000 --> 00:24:09,600
Point that we should say. 
Okay, this lines of code is 

478
00:24:09,600 --> 00:24:13,200
actually more than enough. 
I think the first question is, 

479
00:24:13,200 --> 00:24:15,800
why are we building this? 
You'd be surprised how many 

480
00:24:15,800 --> 00:24:18,600
things where there's people 
working on this and having a big

481
00:24:18,600 --> 00:24:23,100
debate about the architecture or
the technology or the features. 

482
00:24:23,300 --> 00:24:26,900
If you stand back and say, why 
is this important what customer 

483
00:24:26,900 --> 00:24:30,100
cares about this often? 
There is no customer that cares 

484
00:24:30,100 --> 00:24:32,700
about its just somebody in the 
organization thought. 

485
00:24:32,700 --> 00:24:36,600
This would be an interesting 
idea, the easiest way to reduce 

486
00:24:36,600 --> 00:24:40,300
the code is not to write. 
It is what we're batting really 

487
00:24:40,300 --> 00:24:42,600
essential. 
Is there a way that we can 

488
00:24:42,600 --> 00:24:46,600
simplify that into a mechanism, 
which is much more compact. 

489
00:24:46,600 --> 00:24:49,900
So, essentially we can replace 
something that's hard coded with

490
00:24:49,900 --> 00:24:52,200
an interpreter, which is easier 
to change. 

491
00:24:52,300 --> 00:24:55,800
Clearly the number developers 
influences, this from my point 

492
00:24:55,800 --> 00:24:58,300
of view, I think that if you 
have an IDE, it shouldn't allow 

493
00:24:58,300 --> 00:25:01,500
you to scroll that will limit 
the size of a function or a 

494
00:25:01,508 --> 00:25:03,300
method so it has to fit on the 
screen. 

495
00:25:03,300 --> 00:25:06,600
Maybe you can get smaller font 
if you want larger methods, As 

496
00:25:06,600 --> 00:25:09,600
soon as you get into a world 
where you have to scroll, or 

497
00:25:09,600 --> 00:25:13,700
basically you have to use emacs 
to find where the functions are 

498
00:25:13,700 --> 00:25:16,700
and so on, I think you just get 
lost in the complexity, the, 

499
00:25:16,700 --> 00:25:19,100
even the tooling, right? 
I mean, you get the latest 

500
00:25:19,100 --> 00:25:22,300
release of Visual Studio or 
Eclipse, it really doesn't 

501
00:25:22,300 --> 00:25:25,000
matter. 
There's more knobs and dials and

502
00:25:25,000 --> 00:25:28,200
ways to do things. 
So you just put more and more 

503
00:25:28,200 --> 00:25:31,700
complexity on the people. 
And often a lot of the 

504
00:25:31,700 --> 00:25:34,700
functionality is there, you 
don't need it's not, obviously 

505
00:25:34,700 --> 00:25:38,000
layered is their stock. 
Off in some Corner someplace. 

506
00:25:38,200 --> 00:25:41,800
There's a whole Library you want
to use a framework but it turns 

507
00:25:41,800 --> 00:25:44,500
out you only need two classes in
the framework. 

508
00:25:44,700 --> 00:25:47,600
But as soon as you pull the 
framework, it injects all these 

509
00:25:47,600 --> 00:25:50,600
dependencies into your program 
because you have to know what's 

510
00:25:50,600 --> 00:25:53,800
inside the framework. 
So it's not really a component. 

511
00:25:54,000 --> 00:25:57,100
It now becomes part of your 
program Frameworks were the big 

512
00:25:57,100 --> 00:25:59,600
mistake of. 
Oh, oh, the idea was you were to

513
00:25:59,600 --> 00:26:03,700
use a framework inside and then 
you were to have an external API

514
00:26:03,700 --> 00:26:07,000
which was just a value-based so 
you didn't actually Have to know

515
00:26:07,000 --> 00:26:09,900
what the classes were inside the
framework and so on, as you 

516
00:26:09,900 --> 00:26:12,700
didn't have the subclass them 
and so on, but when you use a 

517
00:26:12,700 --> 00:26:15,600
framework, you get to intimate 
with the actual framework and 

518
00:26:15,600 --> 00:26:19,000
now you just create another big 
dependency on. 

519
00:26:19,000 --> 00:26:21,300
So many people's dependencies 
actually aren't the ROM. 

520
00:26:21,300 --> 00:26:24,200
They're dependent on. 
Oh, look at this great library 

521
00:26:24,200 --> 00:26:27,700
that I saw. 
Look at npms, for example, I 

522
00:26:27,708 --> 00:26:30,500
mean, like, you're talking about
the modern Navy technology 

523
00:26:30,500 --> 00:26:32,700
disease as well. 
So many libraries, so many open 

524
00:26:32,700 --> 00:26:35,800
source tools, so many things 
that could be easily installed 

525
00:26:35,800 --> 00:26:39,300
these This could be like a I'm 
install or whatever your 

526
00:26:39,300 --> 00:26:41,800
categorizing this as modern 
tools becoming more and more 

527
00:26:41,800 --> 00:26:44,200
complex. 
It seems that the answer to a 

528
00:26:44,200 --> 00:26:46,300
certain problem is to just build
more stuff. 

529
00:26:46,300 --> 00:26:49,500
So I'm quite fascinated by this 
idea because yeah, there are so 

530
00:26:49,500 --> 00:26:50,900
many things being built these 
days. 

531
00:26:50,900 --> 00:26:53,100
Even my if you look at 
JavaScript library, maybe every 

532
00:26:53,100 --> 00:26:56,000
few days, they will be one being
created out of Any Corner in the

533
00:26:56,000 --> 00:26:58,400
world. 
Good developers, trying to use 

534
00:26:58,400 --> 00:27:02,000
as few libraries as possible. 
That's basically the secret we 

535
00:27:02,000 --> 00:27:04,700
do, we really have to use this 
framework of this library 

536
00:27:04,700 --> 00:27:08,600
because the Is that those things
have a high cost down the road? 

537
00:27:08,600 --> 00:27:12,200
It looks like an easy path but 
often they may go dead. 

538
00:27:12,200 --> 00:27:15,800
The project May Fork. 
Some definitely too much code is

539
00:27:15,800 --> 00:27:19,800
definitely the problem and in 
part contributed to that with 

540
00:27:19,800 --> 00:27:22,600
the whole notion of Frameworks 
and inheritance. 

541
00:27:22,600 --> 00:27:26,200
And so on and stateful 
programming, one of the benefits

542
00:27:26,200 --> 00:27:28,800
of functional programming, is 
that you're much more limited in

543
00:27:28,800 --> 00:27:30,200
the sorts of things that you can
do. 

544
00:27:30,200 --> 00:27:31,900
And in general, that's what we 
really need. 

545
00:27:31,900 --> 00:27:33,500
We need fewer ways of doing 
things. 

546
00:27:33,500 --> 00:27:36,600
For instance, when Amazon came 
out with their first, First 

547
00:27:36,600 --> 00:27:39,000
apis. 
They were very simple, 

548
00:27:39,200 --> 00:27:41,200
basically. 
You just had asked, two, buckets

549
00:27:41,400 --> 00:27:45,100
API was very limited, but the 
good news is, it was easy to use

550
00:27:45,100 --> 00:27:49,300
because the word many ways to do
things now for everything you do

551
00:27:49,300 --> 00:27:52,100
on AWS or any other Cloud 
platform. 

552
00:27:52,200 --> 00:27:55,700
There's at least five other ways
to do it, but I mean, the 

553
00:27:55,700 --> 00:27:58,400
counter-argument will be people 
create these tools with the 

554
00:27:58,400 --> 00:28:00,400
intention of increasing 
productivity. 

555
00:28:00,400 --> 00:28:02,000
Right? 
More Frameworks, more 

556
00:28:02,000 --> 00:28:03,900
abstractions mode. 
Libraries is actually 

557
00:28:03,900 --> 00:28:06,100
encapsulating all those 
unnecessary details. 

558
00:28:06,300 --> 00:28:08,600
Probably developers don't need 
to think about. 

559
00:28:08,800 --> 00:28:11,900
So what about that angle? 
How do you counter this argument

560
00:28:12,000 --> 00:28:13,800
really building more and more 
this for example. 

561
00:28:13,800 --> 00:28:15,900
Aw services. 
So that developers become more 

562
00:28:15,900 --> 00:28:18,700
productive and they just do 
things with a simple API call 

563
00:28:18,700 --> 00:28:20,200
and then we take care of the 
rest. 

564
00:28:20,800 --> 00:28:24,000
I think it's a nice story but 
most of them are written way too

565
00:28:24,000 --> 00:28:26,200
quickly. 
They may be well designed but 

566
00:28:26,200 --> 00:28:29,900
they're certainly not well named
or documented so I don't buy 

567
00:28:29,900 --> 00:28:32,500
that story. 
I think the answer is if 

568
00:28:32,500 --> 00:28:36,100
something is really good it'll 
make its way into a library. 

569
00:28:36,200 --> 00:28:39,400
That's used and not into a big 
tool chain. 

570
00:28:39,600 --> 00:28:41,200
You just look and see, look, 
okay. 

571
00:28:41,200 --> 00:28:44,600
Now because we got event 
oriented programming, we don't 

572
00:28:44,600 --> 00:28:47,200
have a stack anymore. 
So what you have to do is you 

573
00:28:47,200 --> 00:28:50,500
have to turn on tracing and then
you'd get some to get yourself a

574
00:28:50,500 --> 00:28:53,300
honeycomb or some other 
observatories you, so you can 

575
00:28:53,300 --> 00:28:55,700
try and create a stack from this
event. 

576
00:28:55,900 --> 00:28:59,200
Something's wrong here, right? 
It's just too complicated. 

577
00:28:59,200 --> 00:29:02,600
Maybe I'm just old, and don't 
get it, but it just seems like 

578
00:29:02,600 --> 00:29:06,100
it's just too much stuff. 
So, I had an episode yesterday. 

579
00:29:06,300 --> 00:29:09,900
Much semen is referring to 
cognitive load program has brain

580
00:29:09,900 --> 00:29:12,800
these days is really super, 
super intense because they're 

581
00:29:12,800 --> 00:29:14,900
just too many things. 
I could be the state's reading, 

582
00:29:14,900 --> 00:29:17,200
the code could be the tools. 
Understanding the apis. 

583
00:29:17,200 --> 00:29:19,200
The surface areas that you're 
talking about. 

584
00:29:19,300 --> 00:29:22,100
It could be also all these 
orchestration, observability 

585
00:29:22,100 --> 00:29:23,800
tools. 
It seems like these days. 

586
00:29:23,800 --> 00:29:26,700
If you want to be trendy 
developers, you really need to 

587
00:29:26,700 --> 00:29:28,600
master. 
A few of these Technologies 

588
00:29:28,600 --> 00:29:31,400
before you can be considered the
top level of developers. 

589
00:29:31,400 --> 00:29:33,700
In the software, will definitely
the case. 

590
00:29:33,900 --> 00:29:36,100
On the other hand, I think 
there's lots of Smart Companies 

591
00:29:36,200 --> 00:29:38,100
They're looking at things like 
low code. 

592
00:29:38,300 --> 00:29:41,400
The code is not something that 
all lie, aspiring hot, 

593
00:29:41,400 --> 00:29:44,700
developers want and that's good 
because you want them to go. 

594
00:29:44,700 --> 00:29:47,800
Some other place where they can 
have that big mess at that place

595
00:29:47,800 --> 00:29:50,600
with all their tools. 
So I think for normal business 

596
00:29:50,600 --> 00:29:54,100
has low code tools, are a good 
approach, they reduce the 

597
00:29:54,100 --> 00:29:56,100
surface area of what you have to
use. 

598
00:29:56,100 --> 00:30:00,200
They constrain what you can do, 
which is a problem if you want 

599
00:30:00,200 --> 00:30:03,900
to produce the most amazing, 
JavaScript web site or 

600
00:30:04,100 --> 00:30:07,900
microservice architecture. 
It allows people to get things 

601
00:30:07,900 --> 00:30:11,200
done, fairly simply. 
So I think the economics for 

602
00:30:11,200 --> 00:30:14,600
companies that are willing to go
with a local approach are very 

603
00:30:14,600 --> 00:30:16,900
promising. 
There's a lot of choices there 

604
00:30:17,000 --> 00:30:20,100
decades ago, there were things 
called for gl's, which were the 

605
00:30:20,100 --> 00:30:23,000
low code language is of the time
and people were very productive 

606
00:30:23,000 --> 00:30:25,000
in them. 
Now, people look down at them 

607
00:30:25,000 --> 00:30:28,600
because real programmers don't 
program in low code. 

608
00:30:28,700 --> 00:30:31,000
When the end, if you're running 
a business and people are 

609
00:30:31,000 --> 00:30:34,000
successfully knocking at 
applications that seems to me 

610
00:30:34,000 --> 00:30:37,400
like a pretty good idea compared
to Trying to figure out how you 

611
00:30:37,400 --> 00:30:40,400
hire the bright guys who argue 
with each other over, which 

612
00:30:40,400 --> 00:30:42,900
technology and microservice 
architecture. 

613
00:30:42,900 --> 00:30:45,400
They're going to use. 
And so on, I think simpler is 

614
00:30:45,400 --> 00:30:49,400
always better to one thing that 
probably does not get simpler is

615
00:30:49,400 --> 00:30:51,500
the concept of business logic, 
right? 

616
00:30:51,500 --> 00:30:54,000
Depending on the industry, of 
course, these days we need to 

617
00:30:54,000 --> 00:30:57,400
build more and more highly 
sophisticated rules logic, and 

618
00:30:57,400 --> 00:30:59,200
whatever. 
That is, you mentioned that the 

619
00:30:59,200 --> 00:31:01,600
domain knowledge is actually 
still important. 

620
00:31:01,700 --> 00:31:04,400
So this also goes back to the 
concept of domain driven design,

621
00:31:04,400 --> 00:31:07,300
and all that. 
So, tell us more Why you still 

622
00:31:07,300 --> 00:31:09,400
think domain is still the key 
here? 

623
00:31:09,700 --> 00:31:12,600
I think the challenge here is 
how can we get more developers 

624
00:31:12,600 --> 00:31:16,600
to care more about domains when 
you use to start a new company 

625
00:31:16,700 --> 00:31:19,600
long time ago, you would 
actually had to work in 

626
00:31:19,600 --> 00:31:22,300
different departments so you 
would actually find out what 

627
00:31:22,300 --> 00:31:25,800
purchasing was like and what 
inventory was like and you'd 

628
00:31:25,800 --> 00:31:28,700
meet some people, are those 
people will your links to The 

629
00:31:28,708 --> 00:31:33,100
Domain but now developers stay 
like to only focus on coding. 

630
00:31:33,500 --> 00:31:35,600
They don't want to know any of 
that domain stuff. 

631
00:31:35,600 --> 00:31:39,100
Look, give me the story, but 
what this does is, it burns out 

632
00:31:39,100 --> 00:31:42,600
the product owners or the 
product managers because they 

633
00:31:42,600 --> 00:31:45,100
have to take something that's 
very simple. 

634
00:31:45,100 --> 00:31:49,100
Domain concept and break it down
into almost a task level. 

635
00:31:49,100 --> 00:31:52,500
So, the developer understands it
and to me, if you're breaking 

636
00:31:52,500 --> 00:31:54,800
things down to task level, 
you've missed the point of 

637
00:31:54,800 --> 00:31:56,900
agile. 
Basically means you don't really

638
00:31:56,900 --> 00:32:00,900
have communications anymore. 
You basically are forcing people

639
00:32:00,900 --> 00:32:04,500
to break down all the work into 
tiny things that developers can 

640
00:32:04,500 --> 00:32:06,800
Implement by work for. 
Derivatives. 

641
00:32:06,800 --> 00:32:09,000
And one of the interesting 
things they did is they hired 

642
00:32:09,000 --> 00:32:12,200
graduates out of Science and 
business and they would teach 

643
00:32:12,200 --> 00:32:14,800
them Capital markets, 
essentially, everything about 

644
00:32:14,800 --> 00:32:17,700
stocks and options the domain, 
and they would teach them how to

645
00:32:17,700 --> 00:32:21,600
program in the queue functional 
programming language. 

646
00:32:22,000 --> 00:32:25,300
But to the employers, they were 
super attractive because they 

647
00:32:25,300 --> 00:32:29,000
could go in to a company like 
the stock exchange in Singapore,

648
00:32:29,000 --> 00:32:32,500
for example, and they could be 
productive because the business 

649
00:32:32,500 --> 00:32:34,100
people could communicate with 
them. 

650
00:32:34,300 --> 00:32:36,000
They actually knew the 
difference with swap on. 

651
00:32:36,100 --> 00:32:39,500
An option, what the rules were 
and so on things like them. 

652
00:32:39,700 --> 00:32:44,100
So it really allows efficiency 
in the organization because now 

653
00:32:44,100 --> 00:32:47,600
the business and the developers 
are speaking the same language. 

654
00:32:47,800 --> 00:32:51,000
So I think it's a very, very 
important thing to train 

655
00:32:51,000 --> 00:32:55,300
developers in the domain because
you cut down all this overhead. 

656
00:32:55,600 --> 00:32:58,400
The other thing is that there 
are techniques like decision, 

657
00:32:58,400 --> 00:33:01,800
tables, State, tables, 
spreadsheets, that work really 

658
00:33:01,800 --> 00:33:05,600
well for business people and 
those can be automated into 

659
00:33:05,600 --> 00:33:07,700
code. 
Instead of writing a bunch of 

660
00:33:07,700 --> 00:33:12,400
story cards then coating them 
into Java or go you can automate

661
00:33:12,400 --> 00:33:15,300
these, they're just data-driven 
so you can change and these are 

662
00:33:15,300 --> 00:33:17,900
very old techniques but they 
work very well and they're very 

663
00:33:17,900 --> 00:33:19,500
good for capturing business 
knowledge. 

664
00:33:19,700 --> 00:33:22,800
Most people that business can 
put their rules in a table or 

665
00:33:22,800 --> 00:33:26,100
they can put their calculations 
in a spreadsheet or they can put

666
00:33:26,100 --> 00:33:28,600
their workflow in some sort of 
State machine or state 

667
00:33:28,600 --> 00:33:31,700
transition diagram. 
These are generic techniques, 

668
00:33:31,700 --> 00:33:34,900
they're very powerful yet. 
Many programmers aren't taught 

669
00:33:34,900 --> 00:33:37,300
them in school. 
They're not familiar with them 

670
00:33:37,300 --> 00:33:40,100
and so they end up hard-coding 
all these things. 

671
00:33:40,300 --> 00:33:43,200
So the calculation JJ you should
just be able to change your 

672
00:33:43,200 --> 00:33:45,800
spreadsheet and deploy it and 
run it today. 

673
00:33:45,800 --> 00:33:49,300
We can run spreadsheets at 
blazing speed over trillions of 

674
00:33:49,300 --> 00:33:52,400
rows of data. 
We don't need to hard code that 

675
00:33:52,400 --> 00:33:55,300
in Java per se. 
The other thing to talk to Eric 

676
00:33:55,300 --> 00:33:58,500
Evans, I don't think it's enough
emphasis on domain language. 

677
00:33:58,700 --> 00:34:01,700
If you actually captured the 
main language in the old days, 

678
00:34:01,700 --> 00:34:05,200
we call it a data dictionary. 
If you has actually a well-known

679
00:34:05,200 --> 00:34:06,800
vocabulary. 
Definitions. 

680
00:34:06,800 --> 00:34:10,500
And so on those names travel 
through the architecture in the 

681
00:34:10,500 --> 00:34:13,699
code so that you can actually 
relate the words in the 

682
00:34:13,699 --> 00:34:17,699
requirements and the words in 
the stories and in the code, in 

683
00:34:17,699 --> 00:34:21,000
the architecture, you can get 
this overall flow so you can 

684
00:34:21,000 --> 00:34:23,699
find out what happens versus. 
If you just go into a code base,

685
00:34:23,699 --> 00:34:27,900
you find programmer names. 
They're either XYZ or some 

686
00:34:27,900 --> 00:34:31,199
horrible elongated thing that 
you can hardly type and it takes

687
00:34:31,199 --> 00:34:34,699
up all the space on your screen.
So what you want is to reflect 

688
00:34:34,699 --> 00:34:38,400
the domain in the Code, so that 
it's easier to understand. 

689
00:34:38,400 --> 00:34:42,000
So companies that want to make 
it go fast, they invest in 

690
00:34:42,000 --> 00:34:45,000
making sure the developers 
understand the domain it should 

691
00:34:45,000 --> 00:34:47,699
be ever going to be in a 
business transitioning from a 

692
00:34:47,707 --> 00:34:51,800
developer to someone in a 
start-up, you learn very quickly

693
00:34:51,800 --> 00:34:54,199
that speaking the language of 
the customers speaking, the 

694
00:34:54,199 --> 00:34:57,200
language of the domain, it's 
absolutely critical to success. 

695
00:34:57,500 --> 00:35:00,600
The customers don't come to you 
then, describe exactly what they

696
00:35:00,600 --> 00:35:03,600
want. 
They expect you as a Founder to 

697
00:35:03,600 --> 00:35:05,900
have this vision and to be able 
to articulate it. 

698
00:35:06,200 --> 00:35:09,800
Them in their own vocabulary. 
I have two things that I want to

699
00:35:09,800 --> 00:35:12,600
ask you as well first. 
It's about working in startups, 

700
00:35:12,800 --> 00:35:15,500
a lot of startups actually. 
Although some work in well-known

701
00:35:15,500 --> 00:35:18,500
domains like Financial 
technology Medical but maybe the

702
00:35:18,500 --> 00:35:21,800
founding members are not super 
business experts. 

703
00:35:22,100 --> 00:35:24,400
So these knowledge actually is 
not there. 

704
00:35:24,700 --> 00:35:26,900
What will be your suggestion for
these people? 

705
00:35:27,100 --> 00:35:29,900
They have the passion to work in
a start-up building products, 

706
00:35:30,100 --> 00:35:32,600
but they don't necessarily have 
the business expense so they 

707
00:35:32,600 --> 00:35:35,500
hire product managers which is a
generic product managers and 

708
00:35:35,500 --> 00:35:38,000
having to be And a specialized 
domain software. 

709
00:35:38,400 --> 00:35:41,000
So, this is, I think, one of the
key trends these days, why? 

710
00:35:41,000 --> 00:35:43,200
Probably software product is not
optimized. 

711
00:35:43,800 --> 00:35:46,700
I definitely agree with you. 
I think the problem is generic 

712
00:35:46,700 --> 00:35:50,000
programming, a generic product 
person, generics are really 

713
00:35:50,000 --> 00:35:53,100
never all that useful. 
In the sense that what you 

714
00:35:53,100 --> 00:35:56,200
really want is someone that has 
some value, they have experience

715
00:35:56,200 --> 00:35:59,600
in building real-time Control 
Systems, that's why you're 

716
00:35:59,600 --> 00:36:01,400
hiring them. 
You're hiring them for their 

717
00:36:01,400 --> 00:36:05,100
expertise, the way in which we 
like to do is where you can is 

718
00:36:05,100 --> 00:36:06,500
work with domain X. 
Bert's. 

719
00:36:06,900 --> 00:36:09,200
So, if you're going to be 
working in that particular, 

720
00:36:09,200 --> 00:36:12,100
application area, where you want
to do is find those domain 

721
00:36:12,100 --> 00:36:14,200
experts. 
They're more important because 

722
00:36:14,200 --> 00:36:16,500
what you need to do is get 
steeped in domain. 

723
00:36:16,800 --> 00:36:19,200
So it's better to engage with 
two or three real domain, 

724
00:36:19,200 --> 00:36:22,900
experts or someone that's 
retired, maybe or they've done 

725
00:36:22,900 --> 00:36:26,500
very well and they're able to 
spare you the time but you can 

726
00:36:26,600 --> 00:36:30,300
essentially learn from them and 
build your kind of domain model 

727
00:36:30,300 --> 00:36:33,300
and your understanding before 
you get your start up going very

728
00:36:33,300 --> 00:36:35,300
far. 
The problem is once you start 

729
00:36:35,300 --> 00:36:38,500
coding, You're in trouble. 
Basically, then you're already 

730
00:36:38,500 --> 00:36:41,500
committed, you've got to 
schedule, you've got to release 

731
00:36:41,500 --> 00:36:43,900
plan. 
So it's all about investing in 

732
00:36:43,900 --> 00:36:47,600
the right places before you 
start coding because the more 

733
00:36:47,600 --> 00:36:52,000
you can Define described in 
words and in the architecture, 

734
00:36:52,300 --> 00:36:54,600
the more you'll be able to add 
new people because they'll come 

735
00:36:54,600 --> 00:36:57,800
in say, okay, I see this just 
play the movie, or the talk 

736
00:36:57,800 --> 00:37:00,100
about how we got here, and where
we're going. 

737
00:37:00,100 --> 00:37:03,400
And what's the domain about 
companies that were very good at

738
00:37:03,400 --> 00:37:05,000
this. 
For instance, Bob work started, 

739
00:37:05,000 --> 00:37:07,900
originally you Successful 
consulting firm, I'm sure, you 

740
00:37:07,900 --> 00:37:11,300
know them when they started, 
they had this unique idea of 

741
00:37:11,300 --> 00:37:14,500
having really super business. 
Analyst people who really 

742
00:37:14,500 --> 00:37:17,700
understood given domains. 
And that was one of the things 

743
00:37:17,700 --> 00:37:20,200
that was a real major 
contributor impressed me very 

744
00:37:20,200 --> 00:37:24,100
much when I met Roy and his team
many years ago, they had 

745
00:37:24,100 --> 00:37:27,200
business analyst who had Decades
of experience in a given 

746
00:37:27,200 --> 00:37:29,500
industry. 
So, when they went to work with 

747
00:37:29,500 --> 00:37:32,900
a customer, the thought Works 
team had the benefit of this 

748
00:37:32,900 --> 00:37:35,900
person that really understood 
the domain, had the whole 

749
00:37:36,000 --> 00:37:39,200
Vocabulary could relate to the 
customer and I think that's 

750
00:37:39,200 --> 00:37:42,000
something that you really want 
someone that has experience 

751
00:37:42,000 --> 00:37:45,400
understands the customer. 
So if you can bring someone like

752
00:37:45,400 --> 00:37:48,500
that in your startup, whether 
it's someone that comes in as a 

753
00:37:48,500 --> 00:37:51,700
resource in the evenings of the 
weekends and say, look what is 

754
00:37:51,700 --> 00:37:53,800
this? 
General ledger thing, right? 

755
00:37:53,800 --> 00:37:55,300
I hear they have this in 
accounting. 

756
00:37:55,300 --> 00:37:58,300
What is it? 
It really helps you that context

757
00:37:58,300 --> 00:38:01,500
is very important and people 
don't invest enough in 

758
00:38:01,500 --> 00:38:04,800
understanding to me. 
Yeah, I think I agree with you. 

759
00:38:05,000 --> 00:38:07,000
I mean, many people many 
Software development teams. 

760
00:38:07,000 --> 00:38:09,800
Do not invest enough in 
understanding business domain 

761
00:38:10,000 --> 00:38:12,300
because you mention about as 
soon as the code is written, 

762
00:38:12,300 --> 00:38:13,900
right? 
Not only that, as soon as the 

763
00:38:13,900 --> 00:38:17,000
investment comes in, as soon as 
the turnover is starting, or as 

764
00:38:17,000 --> 00:38:19,900
more and more people joining the
company, then it's a total mess 

765
00:38:19,900 --> 00:38:24,000
because there's no clear picture
of what the software is doing. 

766
00:38:24,100 --> 00:38:26,300
There's no same understanding 
about the domain. 

767
00:38:26,800 --> 00:38:29,300
So, I think that is the current 
challenge of software industry. 

768
00:38:29,900 --> 00:38:32,400
Yeah, I don't think you should 
take much money until you 

769
00:38:32,400 --> 00:38:34,100
actually figured out what you're
doing. 

770
00:38:34,400 --> 00:38:36,700
That's not the tendency, but 
Most of business. 

771
00:38:36,700 --> 00:38:38,300
I know that have been 
successful. 

772
00:38:38,300 --> 00:38:41,600
I've actually spent a good deal 
of time early on thinking about 

773
00:38:41,600 --> 00:38:44,900
what they're doing understanding
it and not taking money. 

774
00:38:45,100 --> 00:38:48,500
Because as soon as you get VC 
money in your on the wheel you 

775
00:38:48,500 --> 00:38:50,900
just have to run faster and get 
more done. 

776
00:38:50,900 --> 00:38:54,300
Get more customers and it just 
doesn't in the other thing that 

777
00:38:54,300 --> 00:38:56,600
you mentioned that I was 
fascinated about because last 

778
00:38:56,600 --> 00:38:59,800
time I used to work in insurance
industry, I was working with 

779
00:38:59,800 --> 00:39:02,200
actuary people building this 
point of sale system where you 

780
00:39:02,200 --> 00:39:04,700
calculate the benefits and all 
that and they all use 

781
00:39:04,700 --> 00:39:08,100
spreadsheets this dish. 
Shun tables calculators and all 

782
00:39:08,100 --> 00:39:10,200
that. 
And we programmers have to 

783
00:39:10,200 --> 00:39:13,400
convert the head, complex 
spreadsheet into code, which 

784
00:39:13,400 --> 00:39:16,000
sometimes when you look at it 
you can't even tell. 

785
00:39:16,000 --> 00:39:18,400
Okay, this calculation is 
actually as simple as a 

786
00:39:18,400 --> 00:39:20,800
spreadsheet calculation. 
So I think what you mentioned 

787
00:39:20,800 --> 00:39:23,700
here, maybe we could just 
leverage your decision tables or

788
00:39:23,700 --> 00:39:26,500
spreadsheet, even to build 
programs, instead of having to 

789
00:39:26,500 --> 00:39:29,200
write lines of code in general 
programming language. 

790
00:39:29,300 --> 00:39:32,200
So, maybe can explore a little 
bit more here because I rarely 

791
00:39:32,200 --> 00:39:35,200
see people doing this. 
Take a look at things like are 

792
00:39:35,200 --> 00:39:38,600
table and So on there's a whole 
lot of these sort of local code 

793
00:39:38,600 --> 00:39:41,300
systems and you'll see that 
they're really about 

794
00:39:41,300 --> 00:39:44,800
spreadsheets that mean in the 
IBM analytics environment we did

795
00:39:44,800 --> 00:39:48,000
a analytics in a spreadsheet. 
So even though you Computing 

796
00:39:48,000 --> 00:39:50,800
over a trillion Rose, it was 
still managed in the 

797
00:39:50,800 --> 00:39:52,900
spreadsheet. 
You can actually just run 

798
00:39:52,900 --> 00:39:56,300
spreadsheets, there's no reason 
to give them to a programmer to 

799
00:39:56,300 --> 00:39:58,800
get them wrong. 
It says very straightforward 

800
00:39:58,800 --> 00:40:00,500
algorithm. 
You just have to do a 

801
00:40:00,508 --> 00:40:04,700
topological sort that puts all 
the things in the order and then

802
00:40:04,700 --> 00:40:07,500
put the code and you can Itís, 
simple interpreter. 

803
00:40:07,700 --> 00:40:10,900
You can write one Jabba program 
and it'll run all the 

804
00:40:10,900 --> 00:40:15,000
spreadsheets and back years ago.
Kent Beck worked in a project 

805
00:40:15,000 --> 00:40:17,600
was a small talk project at the 
time, but a big insurance 

806
00:40:17,600 --> 00:40:20,900
company in Chicago. 
They were trying to replace 

807
00:40:20,900 --> 00:40:24,300
COBOL programmers with small 
talk programmers, it went. 

808
00:40:24,300 --> 00:40:28,100
Okay, but didn't go nearly as 
well as the small talk people 

809
00:40:28,100 --> 00:40:32,100
argued it would, this was the 
early days of XP, but then can't

810
00:40:32,100 --> 00:40:35,900
observe that the people who 
negotiated the contracts and the

811
00:40:36,000 --> 00:40:38,000
Curren policies. 
Actually did it all in 

812
00:40:38,000 --> 00:40:41,200
spreadsheets. 
So they actually implemented a 

813
00:40:41,200 --> 00:40:45,400
spreadsheet interpreter, and put
it inside the Mainframe, talking

814
00:40:45,400 --> 00:40:48,100
to the COBOL programs. 
They didn't small talk. 

815
00:40:48,100 --> 00:40:50,600
And they also wrote a rule 
Checker, because spreadsheets 

816
00:40:50,600 --> 00:40:53,400
are usually a mess. 
So before they deployed the 

817
00:40:53,400 --> 00:40:56,600
spreadsheet, they first of all I
had a rule check or so that the 

818
00:40:56,600 --> 00:40:58,000
analysts would be able to do 
this. 

819
00:40:58,000 --> 00:41:01,400
So here's a case of two species 
of special-purpose tooling and 

820
00:41:01,400 --> 00:41:04,800
they were able to automate. 
If you're going to do concurrent

821
00:41:04,800 --> 00:41:08,100
State machines, So you can do 
this high-speed messaging 

822
00:41:08,200 --> 00:41:12,300
asynchronous, microservices, you
have to build a state tables and

823
00:41:12,300 --> 00:41:14,400
you have to be able to 
understand those clearly. 

824
00:41:14,400 --> 00:41:17,700
You can do the simple ones with 
step functions and AWS, but if 

825
00:41:17,700 --> 00:41:19,800
you're building a complicated 
system, you'll have to build 

826
00:41:19,800 --> 00:41:22,900
your own State machines and your
own interpreters for those State

827
00:41:22,900 --> 00:41:25,000
machine. 
So this stuff still works. 

828
00:41:25,200 --> 00:41:27,100
It's been around for decades. 
Yeah. 

829
00:41:27,100 --> 00:41:30,000
Especially acting is still the 
most important tools this day 

830
00:41:30,100 --> 00:41:31,900
because the interface is simple 
enough. 

831
00:41:31,900 --> 00:41:35,000
Many people understand if you 
translate to code, you have to 

832
00:41:35,000 --> 00:41:38,300
do testing, you have Wi you have
to build so many things so it 

833
00:41:38,300 --> 00:41:40,700
becomes a challenge. 
So another thing which you 

834
00:41:40,700 --> 00:41:43,500
mentioned, I know that you have 
been dealing with so many 

835
00:41:43,500 --> 00:41:46,000
different programming language, 
including building. 

836
00:41:46,000 --> 00:41:48,200
Some of those. 
You mentioned that programming 

837
00:41:48,200 --> 00:41:50,700
languages actually met the these
days they are. 

838
00:41:50,700 --> 00:41:53,600
Plenty of programming languages.
They are probably too many to 

839
00:41:53,600 --> 00:41:55,300
learn. 
So there are small. 

840
00:41:55,300 --> 00:41:58,500
Why do you think programming 
languages matter, and how we 

841
00:41:58,500 --> 00:42:01,300
should choose it? 
Actually choosing as much harder

842
00:42:01,300 --> 00:42:03,800
than the other question in the 
end. 

843
00:42:03,800 --> 00:42:05,800
Certainly, there are people who 
disagree about this. 

844
00:42:06,200 --> 00:42:08,700
Some people think that you just 
do the design in the programming

845
00:42:08,700 --> 00:42:10,900
language, doesn't matter. 
I know you've already all cups 

846
00:42:10,900 --> 00:42:14,000
in his view that you just get 
the system design, right? 

847
00:42:14,200 --> 00:42:17,500
But my experience the more code 
you have, the more problems you 

848
00:42:17,500 --> 00:42:19,200
have, the more developers you 
need. 

849
00:42:19,500 --> 00:42:23,200
So, an expressive programming 
language, really reduces the 

850
00:42:23,200 --> 00:42:26,200
amount of code you have and 
increases the rate at which you 

851
00:42:26,200 --> 00:42:28,500
can make change. 
If you have a small code base, 

852
00:42:28,500 --> 00:42:31,500
it's very easy to make changes 
so you can involve the code 

853
00:42:31,500 --> 00:42:34,700
quickly. 
If the language is simple, then 

854
00:42:34,700 --> 00:42:37,900
people don't have to debate. 
Date which library to use which 

855
00:42:37,900 --> 00:42:42,100
API if there's only one way to 
initialize something it's 

856
00:42:42,100 --> 00:42:44,100
simple. 
If there's five ways to 

857
00:42:44,100 --> 00:42:46,400
initialize that you have to go, 
which one should I use? 

858
00:42:46,400 --> 00:42:49,700
And why should I use this? 
Most of the I will call them 

859
00:42:49,700 --> 00:42:54,800
exotic programming languages 
things like Haskell or j or k or

860
00:42:54,900 --> 00:42:57,500
or Lang. 
For example, have very 

861
00:42:57,500 --> 00:43:01,300
expressive ways for handling. 
The kinds of problems that they 

862
00:43:01,300 --> 00:43:03,600
work on. 
No language is ideal for 

863
00:43:03,600 --> 00:43:05,800
everything. 
So a language, that's it. 

864
00:43:06,200 --> 00:43:09,600
With regard to syntax and 
semantics is going to be 

865
00:43:09,600 --> 00:43:12,800
naturally much more productive. 
The other thing is, it's likely 

866
00:43:12,800 --> 00:43:16,800
to have a cleaner implementation
because the number of cases that

867
00:43:16,800 --> 00:43:18,100
the implementers have to work 
with. 

868
00:43:18,100 --> 00:43:22,200
As much smaller, the advantage 
of languages, which don't have 

869
00:43:22,200 --> 00:43:25,200
the library written in the 
language is, you don't get this 

870
00:43:25,200 --> 00:43:29,800
interaction between the runtime 
and the library job of has all 

871
00:43:29,800 --> 00:43:33,200
its libraries written in Java. 
The bad news is that this means 

872
00:43:33,200 --> 00:43:37,800
that a change in the jvm may not
Be reflected in the actual 

873
00:43:37,800 --> 00:43:40,600
libraries when Lambda is were 
added. 

874
00:43:40,900 --> 00:43:42,500
You have to change one thing at 
a time. 

875
00:43:42,500 --> 00:43:46,200
So I'm not criticizing the job 
implementers here to be able to 

876
00:43:46,200 --> 00:43:49,500
do handle things like mapreduce 
efficiently. 

877
00:43:49,600 --> 00:43:53,700
You can put a mechanism in the 
jvm but the library doesn't use 

878
00:43:53,700 --> 00:43:56,000
it. 
So you have this codependency 

879
00:43:56,000 --> 00:43:58,900
between the library and the 
runtime and you have to get both

880
00:43:58,900 --> 00:44:02,500
fixed to do it versus languages 
where the library is, 

881
00:44:02,500 --> 00:44:06,500
essentially written in C or 
machine code, the Library can be

882
00:44:06,500 --> 00:44:10,700
varied tuned versus you. 
Look at python python is not my 

883
00:44:10,700 --> 00:44:13,900
favorite language because I 
don't like white space, but the 

884
00:44:13,900 --> 00:44:16,400
language actually looks like 
it's fairly vast. 

885
00:44:16,600 --> 00:44:19,600
That's because it's actually 
very good at using the same old 

886
00:44:19,600 --> 00:44:23,200
library, some of which are even 
implemented unfortunate and is 

887
00:44:23,200 --> 00:44:27,000
rely on proven libraries that 
are not given to you in the 

888
00:44:27,000 --> 00:44:29,700
source code. 
So I think the advantage of the 

889
00:44:29,700 --> 00:44:31,500
language, we're separate those 
concerns. 

890
00:44:31,500 --> 00:44:34,300
I don't think it's always a 
great idea to have the library 

891
00:44:34,300 --> 00:44:38,000
for your language written in the
Language because again, language

892
00:44:38,000 --> 00:44:42,100
design and Library design is 
hard, if you make it easy, 

893
00:44:42,100 --> 00:44:45,200
people go, oh look I can change 
what object means or some 

894
00:44:45,200 --> 00:44:48,500
nonsense like that or change 
hash or something like that. 

895
00:44:48,600 --> 00:44:51,200
You don't want people making 
those sorts of changes. 

896
00:44:51,400 --> 00:44:54,000
I think I'd be good at everyone.
Got the source code to read for 

897
00:44:54,000 --> 00:44:56,300
the libraries but they weren't 
allowed to change it. 

898
00:44:56,500 --> 00:44:58,500
Source, code is very important. 
It's just you don't want 

899
00:44:58,500 --> 00:45:01,500
everybody changing all the 
source code, I think choosing a 

900
00:45:01,500 --> 00:45:04,800
language, which is simple and 
expressive that is you can learn

901
00:45:04,800 --> 00:45:07,300
it quickly. 
It's Simple consistent set of 

902
00:45:07,300 --> 00:45:09,900
rules. 
As a good implementation, you 

903
00:45:09,900 --> 00:45:12,500
can run a benchmark to see. 
Is it fast enough? 

904
00:45:12,800 --> 00:45:15,900
So if you're choosing a more 
exotic language, you need to 

905
00:45:15,900 --> 00:45:18,800
address those concerns 
responsibly so that you really 

906
00:45:18,800 --> 00:45:22,000
understand that this is going to
work for what you expect. 

907
00:45:22,000 --> 00:45:24,700
And it probably means that if 
you use an exotic language for 

908
00:45:24,700 --> 00:45:28,000
inserter liners, lots of code in
the Erickson switches which is 

909
00:45:28,000 --> 00:45:30,100
written in C, but that's 
perfectly good. 

910
00:45:30,100 --> 00:45:33,900
There's small functions which do
what see does the overall switch

911
00:45:33,900 --> 00:45:35,700
architecture which is serve the 
pie. 

912
00:45:35,900 --> 00:45:38,700
An ultimate microservice 
architecture as well designed 

913
00:45:38,700 --> 00:45:41,700
inner lining supports that, but 
for some of the critical code 

914
00:45:41,700 --> 00:45:43,600
sections, they do the right 
thing. 

915
00:45:43,600 --> 00:45:46,200
They use another language, they 
program the critical code 

916
00:45:46,200 --> 00:45:49,200
performance-wise in C. 
So, I think that's a good 

917
00:45:49,200 --> 00:45:52,600
separation concerned. 
There's no point using Haskell 

918
00:45:52,600 --> 00:45:56,800
to try and compete against CEO 
or rust people may do that. 

919
00:45:56,800 --> 00:45:59,800
But if you want to express 
something, that's got some very 

920
00:45:59,800 --> 00:46:02,300
serious system of types and 
algorithms. 

921
00:46:02,300 --> 00:46:05,600
And so on Haskell's a beautiful 
language for doing that, you can

922
00:46:05,600 --> 00:46:09,100
always Use some other mechanism 
for the low-level pieces of 

923
00:46:09,100 --> 00:46:12,000
code. 
So out of curiosity for Dave, 

924
00:46:12,000 --> 00:46:15,300
Thomas right, if you have to 
choose one popular or Enterprise

925
00:46:15,300 --> 00:46:18,600
language and one exotic language
maybe if we can share with us. 

926
00:46:18,600 --> 00:46:21,600
What will be your two choices? 
The choices? 

927
00:46:21,800 --> 00:46:24,000
I think, probably for an 
Enterprise language today. 

928
00:46:24,000 --> 00:46:28,200
I would choose kotlin. 
So simpler Java is also not this

929
00:46:28,200 --> 00:46:31,000
whipped, so you can get by for 
doing mobile for at least 

930
00:46:31,000 --> 00:46:34,500
Android and so on. 
So I would say, I think Collins 

931
00:46:34,500 --> 00:46:37,100
a nice piece of work. 
And one for exotic. 

932
00:46:37,900 --> 00:46:41,100
OK, I don't even know what that 
is. 

933
00:46:41,300 --> 00:46:42,800
But okay, I'll check it out 
later. 

934
00:46:43,800 --> 00:46:46,900
I'll send you the link. 
Yeah, another thing that you 

935
00:46:46,900 --> 00:46:48,900
mention about working with 
Legacy, right? 

936
00:46:48,900 --> 00:46:51,600
So, a lot of systems these days 
has been built for many years. 

937
00:46:51,800 --> 00:46:54,400
They are legacies. 
They maybe have been written in 

938
00:46:54,400 --> 00:46:57,800
Cobol, Java, whatever that is 
these days, we still have to 

939
00:46:57,800 --> 00:47:00,300
interoperate with them. 
You mentioned something that is 

940
00:47:00,300 --> 00:47:03,200
to me is quite insightful 
instead of doing all this 

941
00:47:03,200 --> 00:47:05,700
rewriting. 
Why don't we just integrate by 

942
00:47:05,900 --> 00:47:08,000
Using a mod data Centric 
approach. 

943
00:47:08,300 --> 00:47:10,400
So if you can tell us a little 
bit more, what do you mean by 

944
00:47:10,400 --> 00:47:12,800
this? 
Sure, I think everyone went to 

945
00:47:12,808 --> 00:47:15,900
the Michael feathers School of 
Legacy transformation. 

946
00:47:16,100 --> 00:47:19,500
He and Michael Nygaard, many of 
the great iäôs speakers talk 

947
00:47:19,500 --> 00:47:23,300
about strangling, your monolith.
But strangling is very expensive

948
00:47:23,400 --> 00:47:25,400
and takes some very talented 
people. 

949
00:47:25,600 --> 00:47:28,200
It works, but it can take two or
three years to take your 

950
00:47:28,200 --> 00:47:30,700
monolith and strangle the 
pieces, and turn it into 

951
00:47:30,700 --> 00:47:33,400
Services. 
The approach that I've advocated

952
00:47:33,400 --> 00:47:35,600
and many others as well. 
Is that changing? 

953
00:47:35,800 --> 00:47:37,600
Code is hard. 
A lot of the times you don't 

954
00:47:37,600 --> 00:47:40,100
even want to change it because 
it's working, fine. 

955
00:47:40,400 --> 00:47:43,100
So the real issues you want to 
introduce new performance or 

956
00:47:43,100 --> 00:47:45,600
functionality new capability in 
the system. 

957
00:47:45,800 --> 00:47:47,500
Listen, natural place to do 
that. 

958
00:47:47,500 --> 00:47:51,000
That's wherever the data is 
stored at rest or moving along. 

959
00:47:51,000 --> 00:47:54,200
So basically, this can be 
streaming data, it can be a 

960
00:47:54,200 --> 00:47:57,500
persistent file or a database. 
It can be a place where 

961
00:47:57,500 --> 00:48:00,000
communication happens between 
programs. 

962
00:48:00,500 --> 00:48:04,400
This is an easy place to have an
intervention, it's an easy place

963
00:48:04,400 --> 00:48:08,500
to insert a new To the nice 
thing is you can essentially put

964
00:48:08,500 --> 00:48:11,700
it in there right into the 
existing system, then divert the

965
00:48:11,700 --> 00:48:15,400
flow so you can just take some 
subset of the transaction so you

966
00:48:15,400 --> 00:48:17,900
can test it. 
You could take like five percent

967
00:48:17,900 --> 00:48:21,200
verify that they're working in. 
So on you can select the 

968
00:48:21,200 --> 00:48:24,000
high-volume transactions and 
say, okay we're going to process

969
00:48:24,000 --> 00:48:26,300
these differently because we 
have too many now. 

970
00:48:26,500 --> 00:48:29,200
Our system is too slow. 
So it's very easy. 

971
00:48:29,200 --> 00:48:31,700
And the nice thing. 
It's easy place to insert new 

972
00:48:31,700 --> 00:48:34,700
technology so it can use. 
For instance, one of my 

973
00:48:34,700 --> 00:48:38,700
favorites is and A database. 
So essentially you can do things

974
00:48:38,700 --> 00:48:40,800
blazingly fast in terms of 
queries. 

975
00:48:40,800 --> 00:48:44,000
And so on, that's essentially 
what honeycomb provides for 

976
00:48:44,000 --> 00:48:47,100
doing observability of their the
amazing database that you can do

977
00:48:47,100 --> 00:48:50,200
queries over to essentially try 
and recover the stack and figure

978
00:48:50,200 --> 00:48:52,700
out what's going on. 
The nice thing is they're fairly

979
00:48:52,700 --> 00:48:55,900
easy to do and you can usually 
do them in three or four months 

980
00:48:55,900 --> 00:48:58,800
so you can complete the whole 
project by putting this new 

981
00:48:58,800 --> 00:49:02,200
technology in place, you can put
new Hardware in place but Intel 

982
00:49:02,200 --> 00:49:06,200
just announced a new chip but 
basically, you know, 4, Dollars.

983
00:49:06,200 --> 00:49:09,200
You get a terabyte of ram, 
another two thousand dollars, 

984
00:49:09,200 --> 00:49:11,700
you get 20, terabytes of nvme 
memory. 

985
00:49:11,900 --> 00:49:15,500
It's got 64 cores. 
I think 48 thousand dollars with

986
00:49:15,500 --> 00:49:17,400
soap. 
You can get massive compute 

987
00:49:17,400 --> 00:49:21,200
capability and you can take that
and you can insert it in the 

988
00:49:21,200 --> 00:49:24,000
appropriate place. 
You can use it for testing but 

989
00:49:24,000 --> 00:49:25,600
these things are all fairly 
straightforward. 

990
00:49:25,600 --> 00:49:28,400
They can be done by a small team
by carefully. 

991
00:49:28,400 --> 00:49:32,100
Looking at the data flows, the 
data provides a natural place 

992
00:49:32,100 --> 00:49:35,700
where you can check and verify 
so testing is much easier. 

993
00:49:35,800 --> 00:49:37,600
As well. 
You can just think about 

994
00:49:37,600 --> 00:49:40,400
decoupling the data stream and 
putting this inside. 

995
00:49:40,500 --> 00:49:43,100
And then using it, it's a very 
powerful technique. 

996
00:49:43,100 --> 00:49:46,400
I've used it for all sorts of 
things for instant, high speed 

997
00:49:46,400 --> 00:49:49,800
data base refactoring, taking a 
database from one technology to 

998
00:49:49,800 --> 00:49:53,300
another technology. 
Just by streaming it full speed 

999
00:49:53,300 --> 00:49:56,700
from one representation to 
another very different approach 

1000
00:49:56,700 --> 00:50:00,700
to how one typically does this. 
Just trying to get the data out 

1001
00:50:00,700 --> 00:50:04,000
using SQL is a nightmare. 
So this thing actually takes the

1002
00:50:04,000 --> 00:50:08,000
pages right from the physical 
And transforms them to pages on 

1003
00:50:08,000 --> 00:50:12,000
another physical store in a 
representation, but the actual 

1004
00:50:12,000 --> 00:50:14,800
algorithm is very 
straightforward, but simple 

1005
00:50:14,800 --> 00:50:19,000
algorithms and the access to 
Modern Hardware, really lets. 

1006
00:50:19,000 --> 00:50:22,400
You make huge changes in an 
organizational system without 

1007
00:50:22,400 --> 00:50:25,100
disturbing very much since it 
doesn't disturb. 

1008
00:50:25,100 --> 00:50:28,100
Very mother isn't a big issue 
about devops changing the data 

1009
00:50:28,100 --> 00:50:30,200
center, doing all that sort of 
stuff. 

1010
00:50:30,300 --> 00:50:32,700
You were just saying, look, 
we're going to take this and 

1011
00:50:32,700 --> 00:50:35,600
we're going to put it in a 
different format and I don't, 

1012
00:50:35,800 --> 00:50:38,100
Think which I learned many 
people think, especially in the 

1013
00:50:38,100 --> 00:50:40,700
micro Service Road data is 
actually an internal. 

1014
00:50:40,700 --> 00:50:43,700
So the service rep should not be
shared or, you know, you should 

1015
00:50:43,700 --> 00:50:46,200
not even care about what 
columns, what data types and all

1016
00:50:46,207 --> 00:50:48,200
that. 
What's your perspective about 

1017
00:50:48,200 --> 00:50:50,400
this? 
If you mention about integrating

1018
00:50:50,400 --> 00:50:52,900
using data Centric approach, we 
need to understand those 

1019
00:50:52,900 --> 00:50:56,000
internals of the data structure.
So what would be your advice 

1020
00:50:56,000 --> 00:50:58,500
here? 
I'm definitely wrong on this so 

1021
00:50:58,500 --> 00:51:01,500
I'm happy to be wrong. 
I actually think that the future

1022
00:51:01,500 --> 00:51:05,900
programming is query. 
The whole issue of having 140 In

1023
00:51:05,900 --> 00:51:08,000
your faces. 
When in the end most of those 

1024
00:51:08,000 --> 00:51:11,400
things are just queries. 
So if you look at graph, F Q, I 

1025
00:51:11,400 --> 00:51:13,400
would actually go further and 
said I think they should be a 

1026
00:51:13,400 --> 00:51:16,500
web SQL, where you can just 
write a query and you should 

1027
00:51:16,500 --> 00:51:19,700
never have to see you rest in 
the things like that, rest can 

1028
00:51:19,700 --> 00:51:21,800
be underneath. 
I understand the properties and 

1029
00:51:21,800 --> 00:51:25,000
so on, but I believe the data 
center city is still a very 

1030
00:51:25,000 --> 00:51:28,400
valuable approach. 
I understand why people do it, 

1031
00:51:28,600 --> 00:51:31,600
but it's like the same thing. 
People don't even want to reuse 

1032
00:51:31,600 --> 00:51:34,700
any code, we don't reuse any 
code, we just write whatever we 

1033
00:51:34,700 --> 00:51:37,800
want. 
So, now, Now you've got 13 or 15

1034
00:51:37,800 --> 00:51:41,400
versions of the same function, 
all different because we're 

1035
00:51:41,400 --> 00:51:43,700
going to move fast. 
Well in the end you're going to 

1036
00:51:43,700 --> 00:51:46,200
have a lot more code and lot 
more codes in your fears. 

1037
00:51:46,700 --> 00:51:48,800
So I think you have to use your 
head. 

1038
00:51:49,000 --> 00:51:52,100
It depends on how often people 
do this for performance. 

1039
00:51:52,300 --> 00:51:55,600
All right, solution, but in the 
end someone still has to 

1040
00:51:55,600 --> 00:51:58,400
understand where all the data is
now. 

1041
00:51:58,400 --> 00:52:01,300
The theory, of course means it's
all moving so you don't need to 

1042
00:52:01,300 --> 00:52:04,200
worry about it. 
I'm not yet convinced that when 

1043
00:52:04,200 --> 00:52:07,400
you look at the architecture, I 
am and you see that everything 

1044
00:52:07,400 --> 00:52:09,600
talks to everything. 
Does that really help you 

1045
00:52:09,600 --> 00:52:11,300
understand? 
If you see those wonderful 

1046
00:52:11,300 --> 00:52:13,400
microservice communication 
patterns? 

1047
00:52:13,700 --> 00:52:15,800
Is that a good thing? 
I don't think so. 

1048
00:52:15,800 --> 00:52:18,600
Everything talks to everything, 
even sometimes you don't have 

1049
00:52:18,600 --> 00:52:21,200
the diagram. 
Yes, he kept us on locks over 

1050
00:52:21,300 --> 00:52:23,500
multiple Services. 
Well, that's why you have to 

1051
00:52:23,508 --> 00:52:26,100
have those tools so you can get 
the guy again. 

1052
00:52:26,500 --> 00:52:29,100
Look, it's always good to be 
able to isolate things and 

1053
00:52:29,100 --> 00:52:31,800
separate them. 
The problem is sometimes that 

1054
00:52:31,800 --> 00:52:35,000
can actually contribute more to 
the complexity it's sort of the 

1055
00:52:35,000 --> 00:52:38,700
same thing as Nosql nosql looks 
like a free lunch. 

1056
00:52:38,900 --> 00:52:42,600
I'm a Ruby programmer. 
So I just stick it in a blob and

1057
00:52:42,600 --> 00:52:45,000
I don't worry about it, makes it
easy for you. 

1058
00:52:45,400 --> 00:52:48,600
But every person that wants to 
look at that data has to write a

1059
00:52:48,607 --> 00:52:52,600
query to unpack that blob. 
So, what you did is you traded 

1060
00:52:52,600 --> 00:52:56,400
your convenience as the 
developer by sucking a nosql 

1061
00:52:56,400 --> 00:53:00,000
blob with the pain of everyone 
who has to actually use that 

1062
00:53:00,000 --> 00:53:02,800
data having to parse it and take
it apart. 

1063
00:53:02,800 --> 00:53:05,500
I think we need to pay a lot 
more attention to how to 

1064
00:53:05,800 --> 00:53:07,800
Queries. 
In fact, if you look at all the 

1065
00:53:07,800 --> 00:53:12,200
new tools, observability honey 
comments on, they're all taking 

1066
00:53:12,200 --> 00:53:14,100
us back to look. 
If you want to understand what's

1067
00:53:14,100 --> 00:53:16,200
going on, you're going to have 
to query all this data, all 

1068
00:53:16,200 --> 00:53:21,700
these traces, I think query is 
kind of the underrated tool, and

1069
00:53:21,700 --> 00:53:25,200
I think it's partly because 
programmers hate SQL, and don't 

1070
00:53:25,200 --> 00:53:28,600
like databases, but the nice 
thing is there are databases 

1071
00:53:28,600 --> 00:53:31,900
which are functional technology 
and which are very powerful and 

1072
00:53:31,900 --> 00:53:34,300
I think as you see and use those
things you go. 

1073
00:53:34,400 --> 00:53:36,800
Oh well, I didn't actually have 
To do all this other stuff. 

1074
00:53:36,800 --> 00:53:38,400
All I had to do is write a 
query. 

1075
00:53:38,800 --> 00:53:41,600
You can even do points to 
analysis and compiler concert. 

1076
00:53:41,600 --> 00:53:45,200
Like, if you look at data log or
was this a talk at Lambda gym, 

1077
00:53:45,200 --> 00:53:47,900
by Simon Marlowe from meta 
Facebook. 

1078
00:53:48,100 --> 00:53:50,600
They've just built a system for 
analyzing programs and 

1079
00:53:50,600 --> 00:53:53,100
essentially, it's all done in 
Haskell course. 

1080
00:53:53,300 --> 00:53:56,400
They basically I've built the 
data log engine so they can 

1081
00:53:56,400 --> 00:53:59,600
query properties about programs 
to try and understand what's 

1082
00:53:59,600 --> 00:54:01,100
happening in different 
programming. 

1083
00:54:01,100 --> 00:54:03,500
Languages and interaction inside
of Facebook. 

1084
00:54:03,800 --> 00:54:06,800
So I think query is the Course, 
for the future. 

1085
00:54:07,600 --> 00:54:09,600
Everyone is moving back to a 
sequel Ezra. 

1086
00:54:09,800 --> 00:54:12,800
So really looking forward to see
the day, we don't need to learn 

1087
00:54:12,800 --> 00:54:14,600
so many different query 
languages. 

1088
00:54:15,100 --> 00:54:18,700
So David's been a pleasant of I 
always learn many new things, so

1089
00:54:18,700 --> 00:54:20,700
it's insightful. 
Not only that, some are 

1090
00:54:20,700 --> 00:54:22,300
unintuitive for me. 
All right. 

1091
00:54:22,400 --> 00:54:25,300
But those things actually make 
sense after you explained about 

1092
00:54:25,300 --> 00:54:28,400
it, unfortunately, due to time, 
we need to wrap up pretty soon. 

1093
00:54:28,700 --> 00:54:31,400
But I would like to ask you one.
Last question that I normally 

1094
00:54:31,400 --> 00:54:34,300
ask for all my guests, which is 
about three technical leadership

1095
00:54:34,300 --> 00:54:36,500
wisdom. 
So this is like an advice for 

1096
00:54:36,500 --> 00:54:38,400
you to all technical leaders 
here. 

1097
00:54:38,400 --> 00:54:40,900
What will be some of the lessons
that you want to share with our 

1098
00:54:41,500 --> 00:54:45,000
scary three questions? 
The first one is actually a 

1099
00:54:45,000 --> 00:54:47,600
quote, from a very famous 
gentleman, called Seymour. 

1100
00:54:47,600 --> 00:54:51,600
Cray who invented, cray, 
Computing, higher than young, 

1101
00:54:51,900 --> 00:54:54,500
they don't know. 
It can't be done if I've had any

1102
00:54:54,500 --> 00:54:57,600
good fortune. 
It's been to hire many young 

1103
00:54:57,600 --> 00:55:00,700
people often, just in their 
second year of University where 

1104
00:55:00,700 --> 00:55:04,800
they're very Innocent, but 
enthusiastic and they do amazing

1105
00:55:04,800 --> 00:55:07,200
things. 
If you hire them with a PhD, 

1106
00:55:07,200 --> 00:55:09,900
they can't do anything because 
they already know all the wrong 

1107
00:55:09,900 --> 00:55:11,800
ways. 
The great thing about young 

1108
00:55:11,800 --> 00:55:13,800
people because they are not 
afraid. 

1109
00:55:14,100 --> 00:55:16,900
So, with discipline and 
guidance, obviously, they do 

1110
00:55:16,900 --> 00:55:20,400
amazing things, don't 
underestimate the young people 

1111
00:55:20,400 --> 00:55:22,800
that you have. 
Access to Singapore, has an 

1112
00:55:22,800 --> 00:55:25,500
amazing pool. 
So exciting place to hire. 

1113
00:55:26,200 --> 00:55:29,600
The next one is focus isn't just
important. 

1114
00:55:29,600 --> 00:55:32,100
It's everything. 
The most important thing you can

1115
00:55:32,100 --> 00:55:34,300
decide every day is what you're 
not doing. 

1116
00:55:34,900 --> 00:55:37,800
Everybody has A big list. 
So the real question is, what is

1117
00:55:37,800 --> 00:55:40,700
that you don't need to do today?
What are you not going to do? 

1118
00:55:40,700 --> 00:55:43,000
Those are the big decisions, 
very simple. 

1119
00:55:43,000 --> 00:55:46,800
But are the last one is that 
every release should have less 

1120
00:55:46,800 --> 00:55:48,700
code in it than the previous 
release. 

1121
00:55:49,200 --> 00:55:51,600
If you're a really great 
software organization, you will 

1122
00:55:51,600 --> 00:55:55,300
figure out how to get more 
function in the release and 

1123
00:55:55,300 --> 00:55:59,000
reduce. 
The code, may only be 3% or 5%, 

1124
00:55:59,200 --> 00:56:02,500
but if you can add new function 
and delete code, you would 

1125
00:56:02,500 --> 00:56:05,400
probably on the way to having a 
maintainable code base. 

1126
00:56:05,700 --> 00:56:09,200
Your code base keeps growing, 
then you have a big maintenance 

1127
00:56:09,200 --> 00:56:11,600
problem and lots of challenges 
ahead of you. 

1128
00:56:12,300 --> 00:56:15,200
I really think the last one may 
be difficult because as we build

1129
00:56:15,200 --> 00:56:17,800
more beaches, normally more 
lines of code, it's being 

1130
00:56:17,800 --> 00:56:19,200
written. 
But thank you so much. 

1131
00:56:19,200 --> 00:56:20,900
And I love the focus question, 
right? 

1132
00:56:20,900 --> 00:56:23,600
Because every day we should 
think about what we should not 

1133
00:56:23,600 --> 00:56:25,600
do today. 
So I think it's always a good 

1134
00:56:25,600 --> 00:56:28,500
question to ponder. 
So Dave, if people want to 

1135
00:56:28,500 --> 00:56:31,400
follow you or continue this 
conversation with you, is there 

1136
00:56:31,400 --> 00:56:32,800
a place where they can reach 
out? 

1137
00:56:33,400 --> 00:56:35,500
So they can go to my Twitter, 
the Indian. 

1138
00:56:35,700 --> 00:56:37,300
Thomas or they can just email 
me. 

1139
00:56:37,300 --> 00:56:39,900
David Bolero.com. 
Thanks very much Henry. 

1140
00:56:39,900 --> 00:56:41,300
It's been really great to talk 
to you. 

1141
00:56:41,300 --> 00:56:43,400
As always, thank you so much for
your time. 

1142
00:56:43,400 --> 00:56:45,900
Really Pleasant conversation. 
Take care. 

1143
00:56:49,000 --> 00:56:52,300
Thank you for listening to this 
episode and for staying, right 

1144
00:56:52,300 --> 00:56:54,800
until the end if you highly 
enjoyed it. 

1145
00:56:54,900 --> 00:56:57,200
I would appreciate if you share 
it with your friends and 

1146
00:56:57,200 --> 00:57:00,200
colleagues who you think would 
also benefit from listening to 

1147
00:57:00,200 --> 00:57:02,300
this episode. 
And if you are new to the 

1148
00:57:02,300 --> 00:57:05,300
podcast, make sure to subscribe 
and leave me your valuable 

1149
00:57:05,300 --> 00:57:07,800
review and feedback. 
It helps me a lot. 

1150
00:57:07,800 --> 00:57:09,800
In order to grow this podcast 
better. 

1151
00:57:10,300 --> 00:57:13,200
You can also find the full show 
notes of this conversation on 

1152
00:57:13,200 --> 00:57:16,900
the episode page at technology 
Arnold death website, including 

1153
00:57:16,900 --> 00:57:20,200
the full transcript enter, 
Testing courts and links to the 

1154
00:57:20,200 --> 00:57:22,500
resources mention from the 
conversation. 

1155
00:57:22,900 --> 00:57:25,900
And lastly, make sure to 
subscribe to the show's mailing 

1156
00:57:25,900 --> 00:57:29,400
list on pack leader know that 
deaf to get notified for any 

1157
00:57:29,400 --> 00:57:32,000
future episodes. 
Stay tuned for the next 

1158
00:57:32,000 --> 00:57:35,300
technology, no episode. 
And until then goodbye.