WEBVTT

1
00:00:01.080 --> 00:00:05.679
How'd you like to listen to dot
NetRocks with no ads? Easy? Become

2
00:00:05.679 --> 00:00:09.839
a patron For just five dollars a
month, you get access to a private

3
00:00:10.000 --> 00:00:14.439
RSS feed where all the shows have
no ads. Twenty dollars a month will

4
00:00:14.439 --> 00:00:19.039
get you that and a special dot
NetRocks patron mug. Sign up now at

5
00:00:19.039 --> 00:00:23.600
Patreon dot dot NetRocks dot com.
Hey, Carl and Richard, here with

6
00:00:23.640 --> 00:00:28.719
your twenty twenty four NDC schedule.
We'll be at as many NDC conferences as

7
00:00:28.760 --> 00:00:33.240
possible this year, and you should
consider attending no matter what. Ndcoslo is

8
00:00:33.240 --> 00:00:37.719
happening June tenth through the fourteenth.
Get your tickets at ndcoslo dot com.

9
00:00:37.759 --> 00:00:43.600
The Copenhagen Developers Festival happens August twenty
sixth through the thirtieth. Early bird discount

10
00:00:43.759 --> 00:00:51.240
ends April twenty sixth. Tickets at
Cphdevfest dot com. Ndcporto is happening October

11
00:00:51.280 --> 00:00:55.920
fourteenth through the eighteenth. The early
bird discount ends June fourteenth. Tickets at

12
00:00:56.039 --> 00:01:11.959
Ndcporto dot com. We'll see you
there, we hope. Hey, guess

13
00:01:11.959 --> 00:01:15.920
what it's dot net rocks. Well
you knew that because you pushed the play

14
00:01:15.959 --> 00:01:19.239
button. I'm Carl Franklin and I'm
Richard Campbell, and we're gonna have a

15
00:01:19.239 --> 00:01:23.159
good show today. Barry O'Reilly is
here. We're going to be talking about

16
00:01:23.239 --> 00:01:27.200
fragility, or anti fragility as he
talks about it. But how are you,

17
00:01:27.280 --> 00:01:32.319
sir, up on the coast back
home? I didn't power out it

18
00:01:32.400 --> 00:01:34.400
yesterday for a couple hours of my
new ups rig. You know, you

19
00:01:34.519 --> 00:01:38.480
find every mistake. Yeah, right, So the network stayed up perfectly,

20
00:01:38.680 --> 00:01:42.599
but it's like, oh, you
plug that monitor into the surge protected outlet,

21
00:01:42.799 --> 00:01:49.200
not the power backed up. So
over the course of the two hours,

22
00:01:49.200 --> 00:01:52.000
I had my head lamp on and
I was running around making fixes on

23
00:01:52.040 --> 00:01:53.799
stuff so that when it all came
back, everything would be better. That's

24
00:01:53.840 --> 00:01:59.719
so so like you, It's so
yes, it's like, oh, powers

25
00:01:59.719 --> 00:02:01.640
out now, I'm busy. I
was busy last week trying to come up

26
00:02:01.680 --> 00:02:07.680
with a solution to a problem that
I couldn't believe was a problem. But

27
00:02:07.039 --> 00:02:17.680
that's my better no framework, So
let's roll the music. Also, apartment,

28
00:02:17.719 --> 00:02:23.000
what do you got all? Right? So everybody does authentication authorization in

29
00:02:23.039 --> 00:02:27.080
a myriad of ways in twenty twenty
four, not one right way. That's

30
00:02:27.080 --> 00:02:30.240
for sure. Oh no. But
you know, if you just select when

31
00:02:30.240 --> 00:02:35.319
you're when you're creating a Blazer application, if you select individual accounts, you

32
00:02:35.360 --> 00:02:42.560
know you're basically buying into the Microsoft
sp net Core identity system and it and

33
00:02:42.639 --> 00:02:47.520
it wants a database, right,
and you can create the template is really

34
00:02:47.520 --> 00:02:52.680
good now. And I got to
say thanks to Jeremy Lecknis and he's not

35
00:02:52.719 --> 00:02:55.240
working on that now, but he's
one of the guys behind all the new

36
00:02:55.360 --> 00:03:01.439
UI in the Blazer template that all
Razor pages now and it's all in there.

37
00:03:01.439 --> 00:03:06.680
You don't have to scaffold anything,
well most of it. But you

38
00:03:06.719 --> 00:03:12.439
know, roles is something that seems
like an antiquated thing, right because everybody's

39
00:03:12.520 --> 00:03:15.879
using claims and building their own claims
and we got claims and servers and two

40
00:03:16.039 --> 00:03:20.520
tokens and all that stuff. But
there's still a case to be made for

41
00:03:20.639 --> 00:03:24.919
simple roles like I want to know
if you know, Joe is in the

42
00:03:25.000 --> 00:03:30.400
admin role so that he can change
things and somebody else isn't simple things like

43
00:03:30.439 --> 00:03:35.000
that, And when it turns out
that those are just strings, they're just

44
00:03:35.080 --> 00:03:38.919
tags, and so it's very easy
for you to they've really turned into claims

45
00:03:39.039 --> 00:03:43.840
effectively a role in a claim is
not that different. Yeah, and in

46
00:03:43.879 --> 00:03:46.360
a role is a type of claim. Right. But here's the deal.

47
00:03:46.520 --> 00:03:50.840
If you're doing a Blazer server application, you just add one line of code

48
00:03:50.879 --> 00:03:54.680
to that template in your program cs, you know, ad roles of identity

49
00:03:54.759 --> 00:04:00.159
role, then you're fine. You
do that in a web assembly applications a

50
00:04:00.159 --> 00:04:03.639
little bit more complicated. Yeah,
now, but there's but but in the

51
00:04:03.680 --> 00:04:10.240
template, there's support for roles in
the you know, in the in the

52
00:04:10.280 --> 00:04:13.080
server side and the client side,
things that talk to each other. It's

53
00:04:13.120 --> 00:04:18.240
just that Oops. They took that
out right before dot net eight went to

54
00:04:18.480 --> 00:04:21.839
you know, in October, right
before dot net eight went live, because

55
00:04:21.920 --> 00:04:26.279
there were situations where you have,
if you have multiple claims with the same

56
00:04:26.399 --> 00:04:30.360
name, they were interfering with each
other, and instead of fixing that,

57
00:04:30.439 --> 00:04:32.240
they punted on it. And it's
still an open issue. So essentially you

58
00:04:32.279 --> 00:04:36.399
don't have roles. Wow. So
basically I figured out a workaround for it.

59
00:04:36.519 --> 00:04:42.519
Wrote a component that's free, and
it's an MIT license component called Blazer

60
00:04:42.800 --> 00:04:47.600
Authorized Roleview And it's a replacement for
the authorized view component that you can use

61
00:04:47.680 --> 00:04:54.079
to you know, authorize markup based
on a role, except that it works

62
00:04:54.240 --> 00:04:58.040
in a web assembly. Uh,
and it's probably a workaround. They'll probably

63
00:04:58.120 --> 00:05:00.920
fix it or they'll come up with
some other solution. Something will change for

64
00:05:00.040 --> 00:05:06.160
nine. Yeah, maybe hopefully.
So that is it. This is show

65
00:05:06.439 --> 00:05:10.439
eighteen ninety six. So if you
go to eighteen ninety six dot pop,

66
00:05:10.600 --> 00:05:14.319
dot me, that will take you
to my repo. And there's also a

67
00:05:14.360 --> 00:05:18.040
Blazer train about it. So that's
what I got. Excellent solve problems.

68
00:05:18.399 --> 00:05:23.240
Cool. Who's talking to us,
Richard crowded commentator Show eighteen ninety four,

69
00:05:23.279 --> 00:05:27.240
the one which is just recently with
Carl Geittz talking about programming and speech,

70
00:05:27.319 --> 00:05:30.120
and this comment comes from Rob who
says, Hey, I really appreciate your

71
00:05:30.120 --> 00:05:33.600
coverage of artificial intelligence. It's positive
and tamps down fear. As an instructor,

72
00:05:33.639 --> 00:05:36.759
I hear a lot of concerns by
other instructors about how AI will affect

73
00:05:36.800 --> 00:05:41.519
students, mostly from the perspective that
a students are using AI to cheat,

74
00:05:41.920 --> 00:05:45.680
but from a programmer's perspective. To
me, it's just another tool, and

75
00:05:45.720 --> 00:05:48.600
it's a really cool tool, but
a tool nonetheless, And the sooner as

76
00:05:48.600 --> 00:05:53.040
instructors that we know how to use
this new tool in the context of whatever

77
00:05:53.120 --> 00:05:56.639
job. We are teaching students to
do the better. So I loaded up

78
00:05:56.680 --> 00:05:59.920
gethub copilot. I use it,
and that has made me realize that,

79
00:06:00.160 --> 00:06:01.920
yes, it makes me faster,
and yes the student could still figure out

80
00:06:01.920 --> 00:06:06.800
syntax more easily, but what's wrong
with that? They still need to learn

81
00:06:06.839 --> 00:06:10.600
the syntax to complete the code.
They still need to learn how to read

82
00:06:10.639 --> 00:06:14.480
the code, and they still need
to understand how complex frameworks are structured and

83
00:06:14.519 --> 00:06:17.319
how to properly and effectively use them. And most importantly, they can still

84
00:06:17.360 --> 00:06:24.959
look forward to hours and hours of
WTF research the figure out how to solve

85
00:06:25.040 --> 00:06:29.879
complex problems that I give them.
Here's zer kind of instructor. It seems

86
00:06:29.920 --> 00:06:33.199
like most of my day is WTF. Yes, a lot of WTF research,

87
00:06:33.360 --> 00:06:38.199
right, just turn on the light. That's got to be a hashtag

88
00:06:38.240 --> 00:06:40.720
man, and AI is likely to
never be able to figure everything out.

89
00:06:40.839 --> 00:06:44.120
That's our job as human beings.
You know. I was recently on a

90
00:06:44.120 --> 00:06:46.800
different podcast. I was on Jeff
Plermo's podcast, and I said, listen,

91
00:06:47.319 --> 00:06:50.560
you know your job's not to write
code. Your job is to find

92
00:06:50.600 --> 00:06:55.879
solutions, right, and if there's
a tool that helps you make they get

93
00:06:55.879 --> 00:06:59.879
to that solution faster, you should
use it. That's the responsible thing to

94
00:07:00.120 --> 00:07:01.560
do exactly. So, Rob,
thank you so much for your comment,

95
00:07:01.600 --> 00:07:03.600
and a copy of music Coby is
on its way to you. And if

96
00:07:03.600 --> 00:07:06.160
you'd like a copy of music Cobe, I write a comment on the website

97
00:07:06.160 --> 00:07:10.319
at dot at Rocks dot com or
on the facebooks you publish every show there

98
00:07:10.319 --> 00:07:12.680
and even comment there at e reading
on the show, we'll send you copy

99
00:07:12.680 --> 00:07:15.600
of music. Go bye music to
code by still going strong. Stuff in

100
00:07:15.759 --> 00:07:20.720
use by thousands, I would say
thousands of people based on my sales.

101
00:07:20.879 --> 00:07:25.079
Dude, it's in this room every
day, like don't don't be crazy,

102
00:07:25.199 --> 00:07:28.920
Like that's the truth. When I'm
home and I got to work mostly writing,

103
00:07:29.040 --> 00:07:32.160
to be honest. Yeah, that's
what's on Cool Blue. I love

104
00:07:32.199 --> 00:07:36.920
Blue. Blue puts me Blue puts
me in the zone. Like click,

105
00:07:38.399 --> 00:07:42.439
that's the first one. Yeah,
okay, Well, you can of course

106
00:07:42.439 --> 00:07:44.759
follow us on Twitter if you want. But the cool kids are hanging out.

107
00:07:44.800 --> 00:07:47.439
I'm mastered on these days. I'm
at Carl Franklin at tech Hub dot

108
00:07:47.480 --> 00:07:53.040
social, and I'm Rich Campbell at
masterd dot social. And you can find

109
00:07:53.079 --> 00:07:56.800
all the ways to get in touch
in the at Carl Franklin dot com All

110
00:07:56.920 --> 00:08:01.279
right, let's get to our guest
who hasn't been on in sickx years Berry

111
00:08:01.439 --> 00:08:07.079
six years. Barry O'Reilly is the
founder of Black Tulip Technology and creator of

112
00:08:07.480 --> 00:08:13.279
residuality theory. He has held chief
architect roles at Microsoft's Western Europe Consultancy practice.

113
00:08:13.560 --> 00:08:20.959
Among others. He's been Microsoft's IoT
Tap lead for Western Europe and worldwide

114
00:08:20.000 --> 00:08:28.040
lead for Microsoft's Solution Architecture Community.
He has also been a startup CTO and

115
00:08:28.199 --> 00:08:33.360
was founder of Sweden's Azure user Group. He's currently finishing up a PhD in

116
00:08:33.440 --> 00:08:39.279
complexity science and software design. I
really want to know about complexity science and

117
00:08:39.440 --> 00:08:48.720
in particular how it helps me oncomplexity
five. Yeah, welcome Berry, Welcome

118
00:08:48.759 --> 00:08:52.639
back. Yeah, heeers. It's
been a long time. A lot,

119
00:08:52.960 --> 00:08:58.240
a lot has happened. Last time
I was on, I was talking about

120
00:08:58.600 --> 00:09:03.799
the con accept of anti fragility and
software and how we can build a software

121
00:09:03.879 --> 00:09:09.879
that appeared to survive on its own
even though it wasn't designed for things,

122
00:09:09.039 --> 00:09:15.279
and that all of those ideas came
out of work you did at Microsoft trying

123
00:09:15.320 --> 00:09:18.440
to teach new architects. So how
do we turn good developers into into great

124
00:09:18.519 --> 00:09:26.240
architects kind of thing, and that
I wrote a paper, and that paper

125
00:09:26.480 --> 00:09:30.000
led to a lot of things,
a lot of attention, and I decided

126
00:09:30.039 --> 00:09:31.600
that I wanted to do things a
little bit differently. So I went back

127
00:09:31.600 --> 00:09:35.600
to school and the things that I
had noticed, the things that i'd written

128
00:09:35.600 --> 00:09:37.960
about, I said, you know, if you don't gather requirements, if

129
00:09:37.960 --> 00:09:41.519
you don't try to predict the future, if you just randomly mix stuff up

130
00:09:41.559 --> 00:09:46.960
and stress and application, you actually
end up with an architecture that's better than

131
00:09:48.039 --> 00:09:52.279
what we normally do. And that's
a very big statement, you know,

132
00:09:52.320 --> 00:09:56.360
and it's it's fun and it's and
I realized that this is the way I've

133
00:09:56.360 --> 00:10:01.000
been working for a very long time. I've given up on process and templates

134
00:10:01.000 --> 00:10:03.799
and all of these things, and
and you know, we're we're all just

135
00:10:03.840 --> 00:10:07.279
making stuff up until it starts to
spin, until the wheel starts to spin,

136
00:10:07.440 --> 00:10:13.159
and the hamster looks happy, right, And I decide, I decided,

137
00:10:13.200 --> 00:10:16.559
you know, this is a wild
claim. And while it's entertaining for

138
00:10:16.600 --> 00:10:18.240
me to go to a conference,
getting a stage and talk to people about

139
00:10:18.240 --> 00:10:22.519
these wild claims, wouldn't it be
great if if they actually had some depth?

140
00:10:22.679 --> 00:10:26.600
So I went back to university,
and I said, I want to

141
00:10:26.639 --> 00:10:30.080
I want to do a PhD.
I want to produce academic work that says

142
00:10:30.080 --> 00:10:33.080
this is real. This is a
scientific this is a scientific fact, not

143
00:10:33.360 --> 00:10:37.000
just not just someone you know,
because if you get up on stage in

144
00:10:37.080 --> 00:10:41.000
I conference, this an amazing thing
happens. People believe you. Yeah,

145
00:10:43.159 --> 00:10:46.879
And and I wanted to, you
know, make it a little bit more.

146
00:10:46.240 --> 00:10:50.279
I wanted to answer the hard questions. And it turns out that that

147
00:10:50.279 --> 00:10:54.840
that's actually was an incredibly difficult thing
to do. And I'm approaching the end

148
00:10:54.879 --> 00:11:01.840
of that process now. I've just
released a little book on Lean pub that's

149
00:11:01.879 --> 00:11:05.080
going to be given away as a
gift at some conferences across Europe in the

150
00:11:05.120 --> 00:11:11.639
next couple of weeks that talks about
the ideas. And so for the last

151
00:11:11.679 --> 00:11:16.720
six years I've been burrowed away writing
frantically and rewriting and testing and teaching people

152
00:11:16.720 --> 00:11:22.440
how to do these things. And
the basic idea that instead of using requirements,

153
00:11:22.440 --> 00:11:26.600
instead of trying to predict what's going
to change and using patterns and encapsulation

154
00:11:26.720 --> 00:11:33.399
and all these methods we've learned over
decades, you can simply start with an

155
00:11:33.480 --> 00:11:37.879
architecture that's really simple that you know
is wrong. One example I use that,

156
00:11:39.200 --> 00:11:43.679
I say to architects, just what
you're allowed one component and all of

157
00:11:43.720 --> 00:11:46.480
your data has to be handled in
memory. You're not allowed to do anything

158
00:11:46.519 --> 00:11:48.919
else. There's one way in,
there's one way out. This is how

159
00:11:48.919 --> 00:11:52.399
we're going to solve the problem.
And if they want to make a change

160
00:11:52.759 --> 00:11:56.360
to that architecture, they have to
suggest something that will cause it to fall

161
00:11:56.399 --> 00:12:00.480
apart. And they say, wow, what happens if we read but then

162
00:12:00.519 --> 00:12:03.000
we lose the in memory data stores? Okay, well you can have a

163
00:12:03.120 --> 00:12:07.080
data store that's you know, find
you deserve state, you've qualified. Yes,

164
00:12:07.159 --> 00:12:13.279
you've justified persistence. So let's do
that, and and the same with

165
00:12:13.399 --> 00:12:16.360
cues and everything else. And you
build your architecture up in that way.

166
00:12:16.279 --> 00:12:22.000
And the funny thing is when you
do this, when you stress your way

167
00:12:22.039 --> 00:12:26.840
to an architecture, you eventually reach
a point, a magical point, where

168
00:12:26.360 --> 00:12:28.960
you can't seem to find a way
to break it anymore. And everything that

169
00:12:30.000 --> 00:12:35.039
you come up with actually is survived
by the architecture. And that's what I

170
00:12:35.080 --> 00:12:39.960
talked about last time. And so
as they've gone away and read an entire

171
00:12:39.039 --> 00:12:43.799
library of books, and complexity,
sciences and philosophy and all sorts of weird

172
00:12:43.840 --> 00:12:48.120
and wonderful stuff. I've managed to
boil this down to a simple theory that

173
00:12:48.159 --> 00:12:52.320
says, this is why this works. This is why there's an actual scientific

174
00:12:52.399 --> 00:12:58.960
reason why you can produce an architecture
just by being incredibly negative. You know.

175
00:13:00.360 --> 00:13:03.799
I just want to point out that
writers, you know, writers of

176
00:13:03.879 --> 00:13:07.759
fiction do this all the time.
Okay, they just have to sit down

177
00:13:07.759 --> 00:13:09.559
and start writing, even nonfiction,
right, Richard. Yeah, sure,

178
00:13:09.720 --> 00:13:13.279
you sit down, you start writing, even if it sucks, even if

179
00:13:13.320 --> 00:13:15.960
you know it sucks, and you
throw lots of it away, throw lots

180
00:13:15.960 --> 00:13:18.440
of it away, but it gets
your brain going. You have at least

181
00:13:18.440 --> 00:13:20.639
somewhere to start. Yeah. And
if you and if you've got somebody watching

182
00:13:20.679 --> 00:13:24.519
over your shoulder saying that's not right, you just want to say, shut

183
00:13:24.600 --> 00:13:26.919
up, you go away. I'm
working it out here, man. Yeah.

184
00:13:28.240 --> 00:13:31.080
And that's that's one of the things
in these ideas that's a huge,

185
00:13:31.679 --> 00:13:35.799
a huge culture shock for I think
for a lot of software developers. Because

186
00:13:35.840 --> 00:13:41.279
we come from computer science backgrounds and
mathematics and stam we're used to having a

187
00:13:41.320 --> 00:13:43.639
formula, We're used to being able
to say this is the correct way to

188
00:13:43.720 --> 00:13:48.200
do this, This is the structured
way, this is this is how you

189
00:13:48.320 --> 00:13:50.519
rationally arrive at an answer. And
this, this way of working is a

190
00:13:50.559 --> 00:13:56.240
little bit wild. You're wrong for
a very long time until suddenly you're right.

191
00:13:56.480 --> 00:14:00.799
And that's a very very different way
of working. And I've shown when

192
00:14:00.799 --> 00:14:05.639
i've shown these ideas, for example, too very senior architects, people who've

193
00:14:05.639 --> 00:14:09.200
built big stuff in azure, and
they've said, yes, this is what

194
00:14:09.240 --> 00:14:15.159
we do. We don't have these
fancy words or this academic waffle, but

195
00:14:15.200 --> 00:14:18.879
we we this is how we think
we're we're you know, negative. And

196
00:14:18.919 --> 00:14:20.480
so if you're an architect, you've
ever been called negative, that's that's a

197
00:14:20.519 --> 00:14:28.679
very good thing. It means you're
doing right. So it's and so it's

198
00:14:28.720 --> 00:14:31.840
starting to I've started to tour these
ideas. I've been at a lot of

199
00:14:31.960 --> 00:14:37.679
conferences. There's a lot of a
lot of views coming on YouTube, kind

200
00:14:37.679 --> 00:14:41.519
of growing interest for the ideas,
and so I've started to publish books on

201
00:14:41.840 --> 00:14:46.960
the subject, and so they're starting
to gather p s and it's it's a

202
00:14:46.039 --> 00:14:50.360
it's a pretty exciting time for these
ideas. I mean, I think the

203
00:14:50.440 --> 00:14:56.799
key point you're making here is that
you're not afraid to constantly revise the architecture.

204
00:14:56.960 --> 00:14:58.919
But I also appreciate, you know, the insight here, which is,

205
00:15:00.320 --> 00:15:03.279
don't start with an architecture like go
minimal so that you're not tearing much

206
00:15:03.559 --> 00:15:09.039
down, you're only adding, yeah, exactly making changes. I tend to

207
00:15:09.039 --> 00:15:13.840
find I go into companies and help
them when they're having some troubles with their

208
00:15:13.919 --> 00:15:18.360
architecture. And sometimes you'll find people
locked in combat over and oh, this

209
00:15:18.399 --> 00:15:22.279
should be an event driven architecture,
or this should be an API driven architecture,

210
00:15:22.320 --> 00:15:26.399
and this is an exting I know, Yeah, how do you know?

211
00:15:26.840 --> 00:15:31.639
Yeah, it's a lot of gut
feeling, and not that there's anything

212
00:15:31.679 --> 00:15:35.440
wrong with gut feeling exact how most
of us do our jobs, but it's

213
00:15:37.320 --> 00:15:41.759
it doesn't become a very concrete discussion
when you're fighting about the differences between these

214
00:15:41.759 --> 00:15:43.960
two different patterns, and so boiling
it down to something simple and saying,

215
00:15:45.360 --> 00:15:48.440
tell me, it's something in the
environment that's going to push this architecture forces

216
00:15:48.480 --> 00:15:54.840
it to behave in this particular way, and and people they can come up

217
00:15:54.840 --> 00:16:00.320
with stories about what might happen in
the environment and what's that happening is that

218
00:16:00.399 --> 00:16:04.799
we're the way that we traditionally build
architectures as we try to gather information from

219
00:16:04.840 --> 00:16:10.639
stakeholders by running around and saying,
tell me your requirements, and they run

220
00:16:10.679 --> 00:16:12.120
away from us. Most of the
time. They don't want to tell us,

221
00:16:12.360 --> 00:16:15.799
and they won't tell us because they
don't really know what the future looks

222
00:16:15.879 --> 00:16:19.279
like. And some people say that
you can capture risk and you can use

223
00:16:19.320 --> 00:16:22.679
probability, or that some people believe
they can predict what's going to change in

224
00:16:22.720 --> 00:16:26.559
an architecture and write all that down. That that's not something I've seen in

225
00:16:26.600 --> 00:16:30.639
my career that's possible for us to
do in a complex kind of business environment.

226
00:16:32.159 --> 00:16:36.519
And so the solution of this problem
is to just randomly simulate the environment.

227
00:16:36.720 --> 00:16:41.320
And so even if you're just making
stuff up and you say, what's

228
00:16:41.360 --> 00:16:47.600
what's going to happen in this in
this system, and you make something up,

229
00:16:47.639 --> 00:16:51.960
you can still find a set of
conditions in which your architecture breaks,

230
00:16:52.080 --> 00:16:55.159
and once you know where breaks,
you can start to make it better.

231
00:16:55.600 --> 00:17:00.720
And it's so I was doing an
example of this. I was talking to

232
00:17:00.799 --> 00:17:03.440
my professor yesterday and he said,
well, you know, you're calling it

233
00:17:03.480 --> 00:17:08.079
a random simulation. If I just
opened a dictionary and just pick a random

234
00:17:08.119 --> 00:17:15.559
word, can you use this to
find out something about the architecture? And

235
00:17:15.599 --> 00:17:18.680
I said, so, we were
talking about building a system for the National

236
00:17:18.720 --> 00:17:22.799
Health Service in Great Britain and he
opened the dictionary and he just pointed a

237
00:17:22.880 --> 00:17:26.160
random word and he said the word
is shed. Can you use this to

238
00:17:26.200 --> 00:17:30.720
make this architecture better? And so
I said, okay, let's just say

239
00:17:30.759 --> 00:17:37.519
that some doctors and nurses start offering
health services in their garden sheds at the

240
00:17:37.519 --> 00:17:41.759
bottom of their gardens. That's absolutely
ridiculous, right, that's probably not going

241
00:17:41.799 --> 00:17:48.759
to happen in the near future.
I'd never say never. And I said,

242
00:17:49.039 --> 00:17:55.000
I'm talking about medical services. So
the question is what impact would that

243
00:17:55.039 --> 00:17:59.960
have in our architecture. Well,
suddenly we're distributed. Our workforce is distributed

244
00:18:00.200 --> 00:18:03.599
in a way that it hasn't been
distributed before, and that puts challenges on

245
00:18:03.640 --> 00:18:07.119
our architecture with updates, with sequences, with all of those things you know

246
00:18:07.119 --> 00:18:11.960
that get nasty when you distribute your
workforce. And I said, okay,

247
00:18:11.000 --> 00:18:15.839
and let's ask what's the path in
our architecture. Can we move to that?

248
00:18:15.039 --> 00:18:18.200
Or is our the architecture that we've
decided on from the start. Is

249
00:18:18.240 --> 00:18:22.799
it so stuck in it's in its
assumption that it can't move to this?

250
00:18:22.839 --> 00:18:25.839
Would it? Would we have to
scrap it and start again. And then

251
00:18:25.880 --> 00:18:29.920
as you talk about it, you
realize actually there there is a movement in

252
00:18:29.960 --> 00:18:34.359
the United Kingdom where people believe that
I guess what you guys call the emergency

253
00:18:34.440 --> 00:18:37.119
room, what we would call A
and E. There are people who want

254
00:18:37.119 --> 00:18:41.839
to have lots and lots and lots
of small emergency rooms in town centers,

255
00:18:41.400 --> 00:18:45.039
you know, especially on a Saturday
night in the UK, where people like

256
00:18:45.079 --> 00:18:48.960
to beat each other up and they
need they need, they need quick access

257
00:18:49.119 --> 00:19:00.119
to healthcare. Then and so,
while the idea that doctors and nurses will

258
00:19:00.119 --> 00:19:06.319
start practicing in their garden sheds is
clearly ridiculous. It's a random data point,

259
00:19:06.359 --> 00:19:10.680
it's a random story, there is
actually what we call in complexity science

260
00:19:10.720 --> 00:19:14.880
and attractor there which is a distributed
workforce that you start to talk about.

261
00:19:15.599 --> 00:19:18.440
And if you solve for the shed, you solve for this potential change in

262
00:19:18.480 --> 00:19:22.680
policy. You don't have to implement
it in your architecture. Now, what

263
00:19:22.720 --> 00:19:26.039
you're looking for is an analogy that
can be triggered by any kind of word

264
00:19:26.200 --> 00:19:33.119
yeah, and any kind of random
now. And so the theory that I've

265
00:19:33.119 --> 00:19:37.759
worked on is that doing this in
this random way on your architecture will actually

266
00:19:37.839 --> 00:19:41.880
give you a better architecture than asking
for requirements or risks, or saying what's

267
00:19:41.920 --> 00:19:45.799
going to change and what's not going
to change, and what I've done,

268
00:19:47.000 --> 00:19:51.960
then what I'll do when I release, if I pass my PhD after the

269
00:19:52.000 --> 00:19:57.359
summer is showed that this actually happens
in a statistically significant way that when when

270
00:19:57.400 --> 00:20:03.839
you do there's a way of measuring
with success of these of these programs,

271
00:20:03.160 --> 00:20:08.319
and you can show that this happens
almost every single time you use this method,

272
00:20:08.640 --> 00:20:14.720
you get an architecture that shows itself
to be able to survive in conditions

273
00:20:14.920 --> 00:20:17.720
which it hasn't been designed for.
I mean, I would argue that even

274
00:20:17.799 --> 00:20:22.200
when you do go in with an
architectural vision initially, there's a halfway point

275
00:20:22.240 --> 00:20:26.839
in almost every project where that gets
substantially revised where you just like, wait,

276
00:20:27.319 --> 00:20:32.039
we now understand this problem much more
deeply. We've done a bunch of

277
00:20:32.079 --> 00:20:33.480
testing. Maybe we've got to it
may even be a V one, but

278
00:20:33.519 --> 00:20:37.559
you're a few features and you're like, we've thought about this wrong, and

279
00:20:37.599 --> 00:20:41.319
if you're lucky, you're able to
make enough changes to be able to deliver

280
00:20:41.559 --> 00:20:48.839
on what the customer actually needed.
Yeah, and that's one of the things

281
00:20:48.880 --> 00:20:55.640
that I talk about, is,
you know, is that the way that

282
00:20:55.680 --> 00:20:59.839
software architecture is being done today at
large companies is kind of in some kind

283
00:20:59.839 --> 00:21:03.799
of gray zone or twilight zone in
terms of what is architecture. And there's

284
00:21:03.799 --> 00:21:08.279
a younger generation of our of developers
who don't want architects in the room.

285
00:21:08.480 --> 00:21:12.319
They'll know, they'll they'll light their
torches and they'll chase you out, and

286
00:21:12.319 --> 00:21:17.039
they'll say go away with your lines
and your boxes and your rules, and

287
00:21:17.759 --> 00:21:21.599
chase you back up into your ivory
tar. And especially within the agile movement,

288
00:21:21.640 --> 00:21:26.039
there's a there's a distrust of architecture
because people have been burned by these

289
00:21:26.039 --> 00:21:32.359
big upfront plans. And and that
means that a lot of times we'll will

290
00:21:32.599 --> 00:21:37.599
architecture is seen as something that's just
going to emerge over time. And and

291
00:21:37.599 --> 00:21:40.680
and like you said, as you
move through a project, you learn and

292
00:21:40.720 --> 00:21:44.160
you find things out, and suddenly
one day the team gets to a point

293
00:21:44.200 --> 00:21:48.160
and this can be very far down
the line where the architecture won't move anymore.

294
00:21:48.240 --> 00:21:52.039
So we'll we've just discovered that this
is all wrong and we can't save

295
00:21:52.119 --> 00:21:55.680
it with a simple refactory. They
have to tear it all down. And

296
00:21:55.720 --> 00:21:57.559
then project management will come in and
say, no, we're not going to

297
00:21:57.599 --> 00:22:02.359
tear it all down. We'll just
keep building on top of this very shaky

298
00:22:02.359 --> 00:22:07.880
platform and we'll call it technical debt. So it sounds good, and that's

299
00:22:07.920 --> 00:22:11.440
where that's where we're going. And
what I'm trying what what I'm trying to

300
00:22:11.599 --> 00:22:18.720
get architects to understand is that there
are three major challenges to software architecture that

301
00:22:18.720 --> 00:22:23.519
that we really don't know how to
handle yet. And those three things are

302
00:22:23.680 --> 00:22:27.720
time, because your architecture we dross
and if you look at someone's architecture,

303
00:22:27.720 --> 00:22:32.759
it's two dimensional diagram with lines and
boxes, and that will not stay to

304
00:22:32.759 --> 00:22:34.720
the saame ever over time, and
there's an idea that it should do.

305
00:22:36.759 --> 00:22:40.640
And then there's change. Over time, things are going to change, and

306
00:22:40.680 --> 00:22:44.720
that's the big problem. That's why
time is nasty. And the problem with

307
00:22:44.759 --> 00:22:48.160
that change is that we don't know
what it is. You can't sit down

308
00:22:48.200 --> 00:22:52.759
and figure out what's going to change
because it's a complex business environment and everything

309
00:22:52.839 --> 00:22:56.240
is moving all at once. So
the market and the customers and the employees

310
00:22:56.279 --> 00:23:00.720
and your competitors, everyone's moving.
You don't know what's in the future.

311
00:23:00.880 --> 00:23:03.880
You can definitely, if you go
back to partner US, you can definitely

312
00:23:03.880 --> 00:23:07.359
say the database connection strengths, we
know that's going to change. We can

313
00:23:07.440 --> 00:23:11.160
encaptulate that will be okay if we
do that. But you don't know what's

314
00:23:11.200 --> 00:23:15.599
going to happen in your market.
And so what I find was that when

315
00:23:15.599 --> 00:23:21.279
we do architecture, architects talk to
each other through two dimensional diagrams, but

316
00:23:21.400 --> 00:23:25.319
in their heads they carry around the
picture. Everyone has different pictures of many

317
00:23:25.359 --> 00:23:29.640
potential futures, many fears and diets
and things that could go wrong. And

318
00:23:29.720 --> 00:23:33.400
so what I wanted to do is
to develop a way of designing architecture that

319
00:23:33.480 --> 00:23:40.079
actually made it easy to capture.
This architecture has or a life cycle over

320
00:23:40.119 --> 00:23:44.640
time with many changes, and we
don't know what those are. And the

321
00:23:44.839 --> 00:23:48.920
concept then becomes that this random simulation
that we do where we randomly stress the

322
00:23:48.960 --> 00:23:57.200
thing from any perspective from talking about
sheds, then we can arrive at an

323
00:23:57.319 --> 00:24:04.039
architecture that has an expression of uncertainty
and time and change in it. And

324
00:24:04.200 --> 00:24:10.359
then we can show in a very
simple mathematical way that this architecture is more

325
00:24:10.480 --> 00:24:15.400
likely to survive in conditions which it
hasn't been built for. It's more likely

326
00:24:15.440 --> 00:24:18.680
to survive those requirements or new features
that pop up out of nowhere, those

327
00:24:18.799 --> 00:24:23.559
changes in the market. And there's
a body of evidence for this in the

328
00:24:23.559 --> 00:24:29.640
complexity sciences. So we go back
to the nineteen sixties. A biologist called

329
00:24:29.759 --> 00:24:34.759
Kaufman developed a model for how life
evolved out of a bunch of amino acids,

330
00:24:34.759 --> 00:24:37.920
how they connect to each other,
how they control each other, and

331
00:24:41.240 --> 00:24:44.519
at the end that you can get
these very simple amino acids, and at

332
00:24:44.519 --> 00:24:48.720
the end of the day you have
something insanely complex like humanity. And we

333
00:24:48.799 --> 00:24:52.640
think, oh, it must have
a master designer. Somebody say, must

334
00:24:52.680 --> 00:24:57.440
have architected all of this at the
outset, Yes, And herein we're engaging

335
00:24:57.480 --> 00:25:00.559
in these practices where that's see,
it is like very difficult to do.

336
00:25:00.880 --> 00:25:06.640
Yes, And but the key to
it is the same as the way life

337
00:25:06.680 --> 00:25:11.559
evolved is to randomly stress things until
they take on a structure. And if

338
00:25:11.599 --> 00:25:15.119
the structure is wrong, and you
keep randomly stressing your architecture, it will

339
00:25:15.200 --> 00:25:18.559
die and you have but luckily we
haven't built anything yet, so we can

340
00:25:18.640 --> 00:25:22.000
change it. And what we end
up with is we have this concept of

341
00:25:22.039 --> 00:25:30.440
a residue, and a residue is
an architecture in one particular timeline we have

342
00:25:30.599 --> 00:25:33.799
this is our residue, and it's
whatever is left over in that timeline,

343
00:25:33.839 --> 00:25:38.039
and we change our original structure so
that in that timeline things look a little

344
00:25:38.039 --> 00:25:42.000
bit better for us, maybe not
entirely solve everything, but just just movable,

345
00:25:42.119 --> 00:25:47.319
just survivable. And what we end
up with is describing an architecture as

346
00:25:47.359 --> 00:25:49.839
you start off with your original naive
architecture, which is the first thing you

347
00:25:49.880 --> 00:25:52.920
came up with, which if we're
honest, you know we all do,

348
00:25:53.480 --> 00:25:59.920
and and a whole bunch of these
residues that represent the architecture in different timelines.

349
00:26:00.440 --> 00:26:04.000
And the trick then is to integrate
all of those different architectures into one

350
00:26:04.160 --> 00:26:11.039
single set of components. And we
do that using some tools that we steal

351
00:26:11.079 --> 00:26:17.119
from the complexity sciences called incidence matrices, and we use these matrices to find

352
00:26:17.160 --> 00:26:21.720
out where where is there hidden coupling
in what I've done that's going to stop

353
00:26:21.759 --> 00:26:26.680
this architecture from moving through its different
timelines if it needs to. And those

354
00:26:26.720 --> 00:26:30.759
matrices. In the book, I
describe seven trigger seven refactoring triggers that you

355
00:26:30.799 --> 00:26:33.920
can see just by drawing a simple
matrix and put filled in it with ones

356
00:26:33.920 --> 00:26:40.400
and zeros, and it can actually
guide you to component boundaries. And we're

357
00:26:40.440 --> 00:26:45.279
way outside of object orientation or nouns
and verbs. Now we're building our building,

358
00:26:45.279 --> 00:26:51.759
our component structure, our service structure
based on the different timelines that might

359
00:26:51.799 --> 00:26:56.359
exist in the future of this architecture. And it's a completely different way of

360
00:26:56.400 --> 00:27:00.359
thinking. It sounds very very alien. Compare too. We gather requirements,

361
00:27:00.400 --> 00:27:06.799
we measure all the risks, we
follow some object oriented principles or gang of

362
00:27:06.839 --> 00:27:10.759
four or something that then we build
the system. This is a much wilder

363
00:27:10.839 --> 00:27:14.920
way of doing architecture, and it
takes people a few days of training to

364
00:27:14.960 --> 00:27:18.680
get into the idea and let go
of all all the old stuff. And

365
00:27:18.680 --> 00:27:23.079
I'm thinking about things in this very
different way, but it does produce fascinatingly,

366
00:27:23.200 --> 00:27:32.799
produces really robust, resilient architectures,
and in a way that's empirically verifiable.

367
00:27:32.799 --> 00:27:37.599
You can show that I've done something
good with a little mathematical formula at

368
00:27:37.599 --> 00:27:41.640
the end of your work, and
that changes everything because as an architect,

369
00:27:41.720 --> 00:27:45.599
for the first time, you can
actually show I've done something useful, which

370
00:27:45.599 --> 00:27:49.960
is hard for architects. I can
see that if you approach the subject with

371
00:27:51.079 --> 00:27:56.000
a word like anti fragility, yeah, that people's first thought might be,

372
00:27:56.240 --> 00:28:00.759
oh, that requires a whole bunch
of front thinking about, you know,

373
00:28:00.920 --> 00:28:07.359
predicting the future, when in fact
it's exactly the opposite, isn't it It

374
00:28:07.440 --> 00:28:11.680
is, yes, it's we're letting
go of this false belief that we can

375
00:28:11.720 --> 00:28:17.000
predict the future. And I think
that's one of the things that enterprise architecture

376
00:28:17.039 --> 00:28:21.720
and waterfall approaches try to sweep under
the rug for generations that yeah, we

377
00:28:21.759 --> 00:28:26.559
can predict the future, we can
build a scenario analysis that's realistic, and

378
00:28:26.640 --> 00:28:30.759
in this methodology we give up all
of that. You've never been able to

379
00:28:30.799 --> 00:28:33.759
do it, We've never successfully done
it. If you're working in a system

380
00:28:33.759 --> 00:28:36.799
where you can predict the future,
then you probably don't need an architect.

381
00:28:36.960 --> 00:28:41.039
It's everything. Everything's easy in that
kind of system. I've never really worked

382
00:28:41.079 --> 00:28:44.680
with any of those, but you
know, it's they may exist. I

383
00:28:44.680 --> 00:28:48.640
haven't seen one well and they're I
mean, I've certainly worked in environments where

384
00:28:48.359 --> 00:28:52.920
they're building the same app over and
over again, essentially, and so the

385
00:28:52.920 --> 00:28:56.920
template does make sense. But yeah, not every most people don't work like

386
00:28:56.960 --> 00:28:59.440
that generally. If you need to
build the same app over and over again,

387
00:28:59.480 --> 00:29:02.319
that app order exists and you shouldn't
need to build it at all.

388
00:29:02.759 --> 00:29:06.319
Yeah, if you're building the same
app over and over again, some SaaS

389
00:29:06.319 --> 00:29:10.920
company is going to come along and
steal your lunch. And so if you're

390
00:29:10.920 --> 00:29:14.680
not building that SaaS company, then
you're going to be in trouble. Eventually,

391
00:29:15.039 --> 00:29:21.359
you're going to get sass. Yeah, but yeah, I mean in

392
00:29:21.400 --> 00:29:23.000
the end, now, recognizing the
body of work that's in front of us

393
00:29:23.039 --> 00:29:27.200
when we're building new software, it's
because it doesn't exist, which means we

394
00:29:27.319 --> 00:29:32.960
really cannot predict the future. So
it makes far more sense for us to

395
00:29:33.160 --> 00:29:38.119
just explore the space over time and
come up with solutions as we go.

396
00:29:40.160 --> 00:29:42.839
It feels to me like the way
you're describing this now is that the technical

397
00:29:44.000 --> 00:29:49.160
debt we're talking about is assumptions made
early that built stuff we never needed.

398
00:29:51.440 --> 00:29:56.000
Yes, the reluctance to change it
once we do realize it because of the

399
00:29:56.039 --> 00:29:59.960
commitments we made to it. Yes, that's very, very dangerous. You'll

400
00:30:00.119 --> 00:30:03.319
find the one way that architects combat
this kind of thing in the past is

401
00:30:03.359 --> 00:30:07.200
that we'll pick a platform, we'll
pick a pattern, and we say this

402
00:30:07.279 --> 00:30:11.599
is the way that we're doing this, and we're because we because we're very

403
00:30:11.599 --> 00:30:14.079
wise, and we've looked into the
future, and we've decided this is how

404
00:30:14.119 --> 00:30:17.359
you solve this problem, right.
And what happens is that as soon as

405
00:30:17.359 --> 00:30:19.839
you put that architecture, rub it
up against reality, it starts to break

406
00:30:19.920 --> 00:30:22.640
a little bit. And the way
we talk about that breaking is we call

407
00:30:22.680 --> 00:30:29.519
it edge cases, and we say
we can't possibly be wrong. So everything

408
00:30:29.559 --> 00:30:33.200
that doesn't work is just an edge
case. It's just a tiny little distraction

409
00:30:33.480 --> 00:30:37.519
on the edge of our of our
knowledge. And that's where you get technical

410
00:30:37.559 --> 00:30:40.799
debt because you start building and hacking
to keep those edge cases and you won't

411
00:30:40.839 --> 00:30:44.759
let go of the architecture. And
so these ideas give us a chance to

412
00:30:45.000 --> 00:30:48.480
question those assumptions very very early.
And the way that the method is set

413
00:30:48.559 --> 00:30:52.839
up, it gives everyone, developers, everyone and the team a chance to

414
00:30:52.920 --> 00:30:56.119
come in and push the architecture around
and say, you know, is it

415
00:30:56.160 --> 00:31:00.599
going to hold in this timeline.
And one way that we've dealt with that

416
00:31:00.640 --> 00:31:03.880
in the past is we use probability
and we say that's never ever going to

417
00:31:03.920 --> 00:31:08.519
happen, right, But by analyzing
this from I'm always afraid of that kind

418
00:31:08.559 --> 00:31:14.839
of certainty. Yeah, exactly.
But one of the things that we've discovered

419
00:31:15.119 --> 00:31:18.880
is that if you take a bunch
of things that are going to happen in

420
00:31:18.880 --> 00:31:22.119
the system, they don't have they
don't have to be accurate because every happening

421
00:31:22.200 --> 00:31:26.519
is part of a class of happenings
that will push the entire system to the

422
00:31:26.640 --> 00:31:30.480
CM kind of state. And if
you solve for that state, then you

423
00:31:30.519 --> 00:31:33.720
solve for many, many, many
things. And what we've discovered is that

424
00:31:33.720 --> 00:31:37.720
there's a simple mathematical leverage. If
you look at it from a complexity science

425
00:31:37.759 --> 00:31:44.519
perspective, a software application is never
actually complex. It's a complicated, constrained,

426
00:31:45.000 --> 00:31:48.599
very ordered thing. We tell it
exactly what to do, and it

427
00:31:48.680 --> 00:31:52.240
only does what we've told it to
do, and sometimes what we think we

428
00:31:52.319 --> 00:31:56.039
told it to do is a little
bit different, but it's very very ordered.

429
00:31:56.599 --> 00:32:00.440
The real complexity in the software system
is in the people and the markets

430
00:32:00.480 --> 00:32:05.799
wandering around changing their minds all the
time. Generally don't have you know,

431
00:32:05.880 --> 00:32:13.039
class libraries that change their minds,
not yet anyway. And and which is

432
00:32:14.759 --> 00:32:21.799
this kind of there's this simple software
system has to live in this massively complex

433
00:32:21.839 --> 00:32:27.119
business environment, and there's such a
huge difference between them that there's a mathematical

434
00:32:27.200 --> 00:32:31.319
relationship between the number of possible states
in them, which means that you don't

435
00:32:31.359 --> 00:32:37.039
have to capture every little bit of
information about the complex state. And so

436
00:32:37.119 --> 00:32:42.640
those waterfall approaches to requirements were always
wrong on a scientific level, the wrong

437
00:32:42.680 --> 00:32:46.559
way to approach things. And so
you only need a sample of those two

438
00:32:47.359 --> 00:32:52.599
to configure your architecture. And that's
why we use the random simulation to make

439
00:32:52.599 --> 00:32:58.359
that sample as broad as possible,
rather than narrowed by by language or by

440
00:32:59.079 --> 00:33:02.319
engineering metaphors that we've imported. And
Barry, I'm gonna interrupt for one moment

441
00:33:02.359 --> 00:33:09.480
for this very important message, and
we're back. It's done at Rocks.

442
00:33:09.480 --> 00:33:13.920
I'm Richard Campbell. That's Carl Franklin. Hey, talking to our friend Barry

443
00:33:13.960 --> 00:33:16.839
O'Reilly, who we see regularly at
conferences but don't talk too near enough.

444
00:33:17.079 --> 00:33:20.359
And I want to push back a
little on what you were saying in the

445
00:33:20.359 --> 00:33:23.319
first half too, because a lot
of that sort of random simulation is like

446
00:33:23.359 --> 00:33:27.640
it still feels like could we just
call that requirements gathering, you know,

447
00:33:27.799 --> 00:33:30.279
but maybe we're testing it with a
bit of code and so forth. This

448
00:33:30.400 --> 00:33:34.400
idea that we're going to catch all
this early, I just don't know that

449
00:33:34.440 --> 00:33:37.720
I buy it, Like, I
think you are going to find things later

450
00:33:37.839 --> 00:33:42.559
on, and the question is how
tolerant are you to being able to adapt

451
00:33:42.880 --> 00:33:47.680
later on? Yeah, And the
methodology builds on that. So one of

452
00:33:47.720 --> 00:33:52.960
the most important concepts is that we
don't know what's going to happen in the

453
00:33:52.960 --> 00:33:58.799
future. We are always going to
get surprised. And if you look at

454
00:33:59.079 --> 00:34:04.880
a business environ a business environment has
tens of thousands and hundreds of thousands of

455
00:34:04.920 --> 00:34:07.119
people in it. It has technology, it has markets, it has politics,

456
00:34:07.159 --> 00:34:09.920
all of these things and they're all
moving all at once. There's no

457
00:34:10.000 --> 00:34:15.039
way that you can predict the movement
of all of these things. And so

458
00:34:15.280 --> 00:34:21.840
the biologist Kaufman showed that when you
have many, many, uncountable number of

459
00:34:21.880 --> 00:34:25.159
things connected to each other, you
don't actually have to predict every tiny little

460
00:34:25.159 --> 00:34:29.920
state of every tiny little piece of
a system. You just have to predict

461
00:34:29.960 --> 00:34:36.519
the presence of a certain number of
things called attractors, and so a large

462
00:34:36.559 --> 00:34:39.679
complex system. You don't learn a
large complex system by grabbing every individual and

463
00:34:39.800 --> 00:34:45.119
understanding their needs and their wants and
their habits and their peculiarities. You observe

464
00:34:45.159 --> 00:34:49.199
the system as a set of attractors
that these things all influence each other and

465
00:34:49.239 --> 00:34:52.000
push each other into And so the
way that you need to work as an

466
00:34:52.119 --> 00:34:58.480
architect is not to identify everything,
but to identify as many attractors as possible.

467
00:34:58.559 --> 00:35:04.119
The moving parts will exactly and once
once you expose your architecture to those

468
00:35:04.159 --> 00:35:09.400
attractors, you start to reach something
which Kaufman the biologists called criticality. And

469
00:35:09.480 --> 00:35:15.639
criticality is the property of a system
where when you start to see that it

470
00:35:15.679 --> 00:35:20.599
survives things that it hasn't been designed
for. And so a very good example

471
00:35:20.639 --> 00:35:23.320
is humanity or a human being.
We survive things all the time that we

472
00:35:23.360 --> 00:35:29.239
don't even know are there. Our
immune systems survive things that they haven't seen

473
00:35:29.320 --> 00:35:32.719
before because of the way they're configured. And Kaufman has this thing called the

474
00:35:32.880 --> 00:35:37.639
NK model that explains it very well. And you have n is the number

475
00:35:37.679 --> 00:35:39.199
of components that you have in a
system, and K is the number of

476
00:35:39.239 --> 00:35:45.840
links, and by optimizing for N
and K in a system, you improve

477
00:35:45.039 --> 00:35:51.559
the system's ability to survive things that
it hasn't been designed for. In software

478
00:35:51.599 --> 00:35:54.039
engineering, we've known this for a
very very long time. We know that

479
00:35:54.079 --> 00:36:00.199
if you allow the number of components
in your architecture to explode, and going

480
00:36:00.239 --> 00:36:05.199
to be harder to kill them all, but it's also going to be extremely

481
00:36:05.239 --> 00:36:07.159
hard to manage them all if you've
got lots and lots of them. And

482
00:36:07.239 --> 00:36:13.119
as you allow the number of connections
between those components to grow, it becomes

483
00:36:13.159 --> 00:36:16.440
incredibly difficult to maintee and because you
have to traceure your messages as they move

484
00:36:16.519 --> 00:36:22.079
between thousands of different channels. And
Kaufman discovered that this exists in biological systems

485
00:36:22.079 --> 00:36:25.760
as well. He calls it the
NK model, and he noticed that as

486
00:36:25.800 --> 00:36:30.400
you tweak certain things the number of
components, the number of links, or

487
00:36:30.440 --> 00:36:32.880
the way they interact with each other, by constraining how often or when they

488
00:36:32.920 --> 00:36:37.719
interact with each other, then you
can control the number of attractors in a

489
00:36:37.800 --> 00:36:43.599
system. And he notes that criticality
is the property that you reach when a

490
00:36:43.639 --> 00:36:47.239
system arrives at the perfect balance of
these things which we call the edge of

491
00:36:47.320 --> 00:36:53.039
chaos and complexity theory, because isn't
the corollary also true that if we have

492
00:36:53.239 --> 00:36:59.519
too few components, we also ended
with a lot of inertia because it becomes

493
00:36:59.519 --> 00:37:01.880
difficult to change them. Yes,
and it becomes very easy to kill the

494
00:37:01.880 --> 00:37:05.760
system because there's only a few components, and if you take out one,

495
00:37:06.360 --> 00:37:10.039
the whole falls apart. And so
there's something we've always known this right as

496
00:37:10.039 --> 00:37:15.000
software engineers. There's something in between
the monolith and the micro service, and

497
00:37:15.000 --> 00:37:19.039
it's never quite the same thing in
different projects. But you have to find

498
00:37:19.039 --> 00:37:22.199
that line, that magic balance,
and that magic balance can be fined through

499
00:37:22.199 --> 00:37:28.360
this random simulation, through stressing the
system until you see that it stands up

500
00:37:28.400 --> 00:37:30.880
on its own. And so instead
of architecture being I'm going to design and

501
00:37:30.920 --> 00:37:36.360
build this beautiful cathedral, architecture becomes
a little more like Bambie on the ice.

502
00:37:36.519 --> 00:37:38.960
Right, We're gonna slip slide,
but eventually we're going to stand up

503
00:37:38.960 --> 00:37:43.599
and everything's going to be okay.
This is absolutely fascinating to me. I'm

504
00:37:43.639 --> 00:37:47.480
just drinking in everything that you're saying
here. And so you have do you

505
00:37:47.480 --> 00:37:51.119
have paper? You said you had
a book or do you have papers other

506
00:37:51.199 --> 00:37:53.519
than your book or is this all
in your book? So it's all in

507
00:37:53.559 --> 00:37:59.239
the book, which is on Lean
pub I have a link to it in

508
00:37:59.280 --> 00:38:02.239
the show notes. Yeah, awesome. The book is based on a series

509
00:38:02.280 --> 00:38:08.159
of seven academic papers that I wrote
over the since we last talked, over

510
00:38:08.239 --> 00:38:10.679
the last six years. And what
I find was I got a lot of

511
00:38:10.679 --> 00:38:15.719
feedback from academic people who said this
is really good, and from a lot

512
00:38:15.719 --> 00:38:19.000
of complexity science people who said this
is really good, and from a lot

513
00:38:19.039 --> 00:38:25.280
of software developers who said, this
makes no sense to us whatsoever. They're

514
00:38:25.280 --> 00:38:30.679
removing the cheese man. Yeah,
and I've built a whole career around introducing

515
00:38:30.679 --> 00:38:34.719
complexity to the beginning of a project. Why are you ruining this for me

516
00:38:35.039 --> 00:38:38.000
with you exactly? And so what
I what I did then? So I'm

517
00:38:38.039 --> 00:38:42.719
working with the conference. The conference
is called the Domain Driven Design Europe,

518
00:38:43.559 --> 00:38:47.639
and I've spoken there a few times
on these ideas, and they called me

519
00:38:47.719 --> 00:38:50.920
last year and said, hey,
we want to give a little book out

520
00:38:50.960 --> 00:38:53.599
as a present to all our attendees. Soul you could you write us a

521
00:38:53.599 --> 00:38:57.480
little book? So I wrote the
book, and I sat down and said

522
00:38:57.519 --> 00:39:00.239
I have to make this something that
that's you know, more in the language

523
00:39:00.280 --> 00:39:06.239
that software engineers are going to grasp
rather than all these fancy complexity terms from

524
00:39:06.320 --> 00:39:10.079
biology and philosophy and all of these
things. And so that book has has

525
00:39:10.159 --> 00:39:19.159
just been released on Lean pub and
it's it's much much easier to understand.

526
00:39:19.800 --> 00:39:22.599
And there's a second book in the
works coming that's more on the philosophy.

527
00:39:22.639 --> 00:39:25.760
So I ended up, you know, digging, going all the way back

528
00:39:25.800 --> 00:39:29.480
to the Presocratics and saying, well, this is where we went wrong.

529
00:39:29.920 --> 00:39:34.719
About three years ago in ancient Greece, a guy made a decision and we've

530
00:39:34.760 --> 00:39:39.239
all been suffering ever since. And
so there's a fair body of work out

531
00:39:39.239 --> 00:39:43.440
there, and there's going to be
you know, a PhD thesis published in

532
00:39:43.440 --> 00:39:45.880
the coming months, and there's going
to be, you know, eventually a

533
00:39:45.920 --> 00:39:52.159
bigger book. Just I mean not
to dive straight into the academics of this,

534
00:39:52.320 --> 00:39:57.920
but part of what makes this methodology
work is that software isn't tangible,

535
00:39:58.239 --> 00:40:01.639
That rebuilding the temple is a button
press away, yes, you know,

536
00:40:01.880 --> 00:40:07.079
or accepting a pull request away.
We did a lot of planning when building

537
00:40:07.119 --> 00:40:10.719
in stone, because getting it wrong
takes a long time to clean up and

538
00:40:13.440 --> 00:40:19.599
replace. It's very difficult to go
from straw to wood to brick where it's

539
00:40:19.639 --> 00:40:22.280
just not in software. Yeah,
the analogy that I use in the book

540
00:40:22.360 --> 00:40:27.199
is the manufacturing of cars. So
and I say, you know, that's

541
00:40:27.199 --> 00:40:29.840
a very planned process, and it
has to be it has to all work,

542
00:40:29.920 --> 00:40:34.760
everything has to fit together. And
that's a kind of engineering. And

543
00:40:34.960 --> 00:40:38.960
whenever software engineers back in the fifties
and sixties, we're looking for credibility,

544
00:40:39.000 --> 00:40:43.960
they wanted to say we're engineers too. So we borrowed a lot of the

545
00:40:44.039 --> 00:40:50.519
engineering metaphor from industries like car manufacturing. And what I say in the book

546
00:40:50.599 --> 00:40:52.800
is, imagine what it would look
like to be the designer of a car

547
00:40:53.440 --> 00:40:59.920
if gravity wasn't constant, if aluminium
constantly changed its properties, if rubber melted

548
00:41:00.239 --> 00:41:04.599
and reformed randomly. Because that's what
our stakeholders do, because we're building on

549
00:41:04.679 --> 00:41:09.679
their ideas, their opinions, and
so using the old school kind of engineering

550
00:41:09.719 --> 00:41:14.559
way of thinking about the world doesn't
work for us. Software is so connected

551
00:41:14.599 --> 00:41:17.920
and so malleable, so connected to
our ideas, and our ideas are fluid

552
00:41:17.920 --> 00:41:22.760
in a way that physical substances just
aren't there. We don't have the equivalent

553
00:41:22.800 --> 00:41:28.039
of the laws of physics to constrain
us. No't we can do anything.

554
00:41:28.199 --> 00:41:30.840
Anything can happen in a software project. And as soon as anything does happen,

555
00:41:30.880 --> 00:41:35.400
the rigid, sort of stiff software, the mechanical part of what we

556
00:41:35.480 --> 00:41:38.760
do falls apart, very very quickly. And that's what I describe as as

557
00:41:38.760 --> 00:41:46.079
the fundamental issue in software engineering,
that things are time changing, uncertainty are

558
00:41:46.239 --> 00:41:50.679
driving what we do. And we've
been spending all our time trying to nail

559
00:41:50.719 --> 00:41:53.960
it down and make it certain right
when we design, and most of the

560
00:41:54.039 --> 00:41:57.719
time we've been lying. And one
of the things I reference in the book

561
00:41:57.760 --> 00:42:00.559
which most people haven't discovered this,
and people have been emailing me saying this

562
00:42:00.599 --> 00:42:09.079
is absolutely hilarious. But David Parnas
wrote a paper in nineteen eighty six called

563
00:42:09.760 --> 00:42:15.400
a Rational Design Process Hi and Why
to feake It? And so this is

564
00:42:15.440 --> 00:42:19.880
one of our is what this is
one of our finding fathers of software engineering,

565
00:42:20.360 --> 00:42:23.599
and he says it's impuls in this
paper, it's impossible to have a

566
00:42:23.679 --> 00:42:30.880
rational, structured way to design software. It just never happens the same way

567
00:42:30.920 --> 00:42:34.960
twice. We're making everything up as
we go along. It's pure mayhem,

568
00:42:35.559 --> 00:42:37.400
and he turns round in the paper
and says, but there's a lot of

569
00:42:37.480 --> 00:42:42.920
value in pretending to management that we
work in a rational and structured way.

570
00:42:43.320 --> 00:42:46.920
And so basically this article is a
call to all software engineers to just lie.

571
00:42:47.199 --> 00:42:53.480
Why just make it look like it's
engineering. And that's absolutely fascinating.

572
00:42:53.559 --> 00:42:58.239
Well, because it makes it makes
the mortals comfortable, it does. Yeah

573
00:42:58.320 --> 00:43:00.039
right, I mean that's really what
it comes down to. And so he

574
00:43:00.119 --> 00:43:05.360
knew this forty years ago, and
so we've been lying to management ever since

575
00:43:05.360 --> 00:43:10.400
about how how unpredictable and unstealable our
methods and our processes are. And you'll

576
00:43:10.400 --> 00:43:14.599
find that in a lot of the
approaches that we use, they promise certainty,

577
00:43:14.639 --> 00:43:19.199
they promise stability, they promise a
repeatable process. If you look at

578
00:43:19.199 --> 00:43:22.400
things like TOGAF and things like see
If that we have nowadays, it's all

579
00:43:22.400 --> 00:43:27.760
about repeatability and everything being concrete and
measured and well understood. And our world

580
00:43:28.199 --> 00:43:31.599
as architects simply isn't like that.
Yeah, wow, Mind Blown Partners is

581
00:43:31.639 --> 00:43:37.000
still alive. He's actually in Victoria, Like I'm almost looking across at where

582
00:43:37.000 --> 00:43:39.480
he lives. Yeah, he's in
his eighties. Like, yeah, man,

583
00:43:40.000 --> 00:43:45.559
I had some email contact with him
a few years ago, and yeah,

584
00:43:45.599 --> 00:43:50.719
we talked a little bit. So
I pointed out that maybe, you

585
00:43:50.719 --> 00:43:54.199
know, maybe the problem that we've
had is not that things change, but

586
00:43:54.239 --> 00:44:00.320
that we don't know what's going to
change, which, well know, I've

587
00:44:00.360 --> 00:44:05.320
been wondering the past few years that
the inertia of our systems have been pretty

588
00:44:05.360 --> 00:44:12.239
stable, and so it's felt more
and more engineering recently. But at the

589
00:44:12.239 --> 00:44:15.559
same time, you know, I
spent a lot of time looking outward.

590
00:44:15.840 --> 00:44:20.400
We're right for disruption. Yeah,
you know, the smartphone's going to change,

591
00:44:20.639 --> 00:44:25.079
likely to augmented reality. These language
these non deterministic language models represent a

592
00:44:25.079 --> 00:44:29.320
whole new X paradigm, Like there's
a bunch of funny things that could happen

593
00:44:29.360 --> 00:44:31.440
here, and boy, oh boy, all your plans can be blown up

594
00:44:31.480 --> 00:44:36.000
pretty good. Yeah. I think
one of the things that's happening is we're

595
00:44:36.039 --> 00:44:39.519
getting better and better at what we
do at the at the software, the

596
00:44:39.639 --> 00:44:44.159
rigid ordered part of what we do. We're getting better at delivering it.

597
00:44:44.239 --> 00:44:46.320
We know that we know how to
test it, we know how to deploy

598
00:44:46.840 --> 00:44:50.840
much more often, We're getting better
at so many of these things. CLOUDE

599
00:44:50.880 --> 00:44:55.480
is this amazing collection of architectural patterns
that makes everyone's life easier. But at

600
00:44:55.480 --> 00:44:59.280
the same time, if you look
out into the real world, people who

601
00:44:59.280 --> 00:45:02.480
are doing business and executives and companies
and governments, they're finding the world that

602
00:45:02.519 --> 00:45:07.760
we live in harder and harder to
manage because they don't know what's coming down

603
00:45:07.840 --> 00:45:14.719
the pipeline or if anything's coming down
the pipeline, and that makes their world

604
00:45:14.880 --> 00:45:19.360
difficulty. Management loves predictability. Yeah, at the same time, we've sold

605
00:45:19.480 --> 00:45:22.480
all of the stuff is predictable when
reality what is it should be allowing for

606
00:45:22.519 --> 00:45:28.760
extreme flexibility. Being able to pay
for your your compute by the minute makes

607
00:45:28.760 --> 00:45:32.039
you more flexible. Being able to
automate the pipeline deploy software means you can

608
00:45:32.079 --> 00:45:37.079
iterate more quickly. These are all
elements of getting to where what you're describing

609
00:45:37.119 --> 00:45:40.280
Barry, which is you don't have
to predict the future. You can keep

610
00:45:40.320 --> 00:45:45.199
adjusting to the present as it comes
at you because all of this infrastructure makes

611
00:45:45.239 --> 00:45:49.079
it very easy to do. So. Yeah, it's the question, you

612
00:45:49.119 --> 00:45:52.159
know, when a customer asks you, do you know how to you know?

613
00:45:52.239 --> 00:45:53.880
Can you do this? Not do
you know? But can you do

614
00:45:54.440 --> 00:45:58.920
X? And most of the time
I answer is yes, even if I've

615
00:45:58.960 --> 00:46:01.239
never done it before, because I
trust in my ability to be able to

616
00:46:01.239 --> 00:46:05.719
figure it out and get it done. And so that is the certainty that

617
00:46:05.760 --> 00:46:09.400
I have that I believe in myself. I believe in my team. Yes,

618
00:46:09.440 --> 00:46:13.960
and I know that we can do
this because we have the ability to

619
00:46:14.440 --> 00:46:16.320
test things out, to look things
up and see where the mistakes have been

620
00:46:16.360 --> 00:46:19.920
made and figure it out. Yes. And this is This is a big

621
00:46:19.960 --> 00:46:22.920
conversation I have with architects when I'm
teaching them, And a lot of times

622
00:46:22.960 --> 00:46:28.519
teaching architects is more like therapy than
actually teaching them anything. Sure well,

623
00:46:28.559 --> 00:46:30.320
one of the things I try to
get them to understand is to say,

624
00:46:30.360 --> 00:46:34.840
why were you successful in your last
project? And a lot of architects will

625
00:46:34.880 --> 00:46:37.159
lean back and and say because I
use this framework or this pattern or this

626
00:46:37.280 --> 00:46:40.719
tool. I was like, no, it's you. You are the success

627
00:46:40.760 --> 00:46:45.119
in your projects. The way that
you think, the flexibility of thought that's

628
00:46:45.159 --> 00:46:49.719
required to build good architectures is what
makes it succeed, and that that exists

629
00:46:49.760 --> 00:46:52.360
only in you and the people around
you. It doesn't exist in a free

630
00:46:52.400 --> 00:46:58.599
A framework boils away that human essence
that makes it possible and that's why one

631
00:46:58.639 --> 00:47:00.760
of the one of the best forms
of feedback that I get is when I

632
00:47:00.800 --> 00:47:05.920
teach these classes or I teach these
workshops, and I have some senior architects

633
00:47:05.920 --> 00:47:08.360
who's built mad stuff that I respect, who says, this is how we

634
00:47:08.519 --> 00:47:13.199
actually think, this is what we
do. That's how I know that I've

635
00:47:13.239 --> 00:47:15.239
hit the kneel on the head because
what I started out, what I set

636
00:47:15.280 --> 00:47:19.159
out to do, was to answer
the question, how do I turn a

637
00:47:19.199 --> 00:47:22.400
developer into an architect? What do
we teach them? Because it's definitely not

638
00:47:22.480 --> 00:47:24.800
too gap, and it's definitely not
requirements, and it's definitely not lines and

639
00:47:24.840 --> 00:47:30.840
boxes. And what I've done is
I've turned that negativity of senior architects into

640
00:47:31.000 --> 00:47:35.599
a two that we can do so
that we're not dismissed anymore, and so

641
00:47:35.679 --> 00:47:37.480
it'll be quiet negative, Nancy.
We just want to get this built,

642
00:47:37.960 --> 00:47:40.800
and we can say, well,
actually, this is the process. And

643
00:47:40.880 --> 00:47:45.960
it turns out that when you start
to work in this random way, it's

644
00:47:45.079 --> 00:47:49.079
so much more fun. And it's
one of the coolest things to watch at

645
00:47:49.079 --> 00:47:52.840
the workshops is when people start building
systems by stressing them, by making mad

646
00:47:52.840 --> 00:47:58.880
stuff up, by picking words out
of a dictionary. Then the fun that

647
00:47:58.880 --> 00:48:01.320
it starts to happen is it's really
really cool, and at the end of

648
00:48:01.360 --> 00:48:06.039
the day you get a verifiable architecture
out of the work. I also wonder,

649
00:48:06.159 --> 00:48:09.559
I mean, there's a psychological aspect
of this. By doing random things,

650
00:48:09.599 --> 00:48:13.639
by not, you know, doing
all this careful planning, you're not

651
00:48:13.960 --> 00:48:17.559
upset when your software breaks, like
you break it all the time. Yeah,

652
00:48:17.559 --> 00:48:22.320
so it's I mean, you take
away that stigma and so, you

653
00:48:22.360 --> 00:48:25.000
know, and you externalize it.
It's like, oh, we did this

654
00:48:25.000 --> 00:48:29.599
thing, we got this result.
This is not personal. This is not

655
00:48:29.760 --> 00:48:34.639
you've failed. This is we were
experimenting. We battered the software, the

656
00:48:34.719 --> 00:48:38.159
software got battered. Good on us. Now let's try something else exactly.

657
00:48:38.519 --> 00:48:45.400
This reminds me of a situation.
I was actually lucky enough to be hired

658
00:48:45.440 --> 00:48:50.679
as a session musician on an album
that was recorded at Levon Helms Studio and

659
00:48:50.719 --> 00:48:53.400
would stuck right, and so I
was hanging around most of the you know,

660
00:48:53.519 --> 00:48:58.159
all I had to do is play
one solo, right, and they

661
00:48:58.239 --> 00:49:00.039
finally got to me on the second
day. I hang around all day the

662
00:49:00.079 --> 00:49:05.239
first day, second day, about
three o'clock. All right, Carl you're

663
00:49:05.320 --> 00:49:08.880
up. And I told them right
at the outset, guys, it's going

664
00:49:08.960 --> 00:49:14.880
to take me about ten nine or
ten takes to really nail this solo.

665
00:49:15.039 --> 00:49:19.119
And they looked at me like I
was crazy, Like what you can't just

666
00:49:19.239 --> 00:49:22.159
like you know, and I said, no, I really have to play

667
00:49:22.199 --> 00:49:24.039
it a few times. I have
to feel it to get some ideas,

668
00:49:24.719 --> 00:49:28.280
and you know, by the by
the tenth take, I swear to God

669
00:49:28.320 --> 00:49:30.239
it's going to be magic. Turns
out I nailed it. It was like

670
00:49:30.440 --> 00:49:37.079
ninth take boom, that was the
one everybody said yes. And it's because

671
00:49:37.119 --> 00:49:43.320
I understood myself and I understood what
my you know, abilities are and how

672
00:49:43.360 --> 00:49:45.239
I can get to it. And
so at the end of the day,

673
00:49:45.239 --> 00:49:51.280
I wasn't sure if I should have
divulged that or I should have just done

674
00:49:51.280 --> 00:49:53.760
it. You know that if I
hadn't said that, maybe they would have

675
00:49:53.760 --> 00:49:58.000
been angry with the fact, like, like, you're wasting our time,

676
00:49:58.320 --> 00:50:00.599
you know, you should just come
in nail it. I don't know,

677
00:50:01.400 --> 00:50:04.960
but it makes me. It just
goes back to that whole thing with having

678
00:50:04.960 --> 00:50:08.639
a belief in your abilities and your
ability to figure stuff out. Right.

679
00:50:09.079 --> 00:50:14.239
It don't look at it as an
unknown look at it is what usually happens

680
00:50:14.239 --> 00:50:16.079
when I don't know something? And
how long does it usually take me to

681
00:50:16.079 --> 00:50:21.159
figure it out? Yeah? And
I think we have an attitude in our

682
00:50:21.440 --> 00:50:25.679
industry which I call sigalism. And
as you know, when you watch a

683
00:50:25.719 --> 00:50:30.719
Steven Siegal movie and he goes into
you know, he goes into a bar

684
00:50:30.880 --> 00:50:32.840
full of bad guys and there's like
fifty of them in there, and they

685
00:50:32.920 --> 00:50:37.519
all rush at him and he beats
everyone up and throws them out through windows

686
00:50:37.519 --> 00:50:40.119
and things. He comes out of
He comes back out of the bar without

687
00:50:40.119 --> 00:50:43.800
a scratch on him. He has
a tiny little bit of dust on his

688
00:50:43.880 --> 00:50:49.199
lapel which he brushes off and then
he goes he drives off again. And

689
00:50:49.239 --> 00:50:52.079
you're thinking, in terms of plot, why would you go in there?

690
00:50:52.199 --> 00:50:57.039
That makes no sense. But in
in tech we tend to think that,

691
00:50:57.119 --> 00:50:59.320
you know, we need to know
everything. I need to go in and

692
00:50:59.400 --> 00:51:01.000
nail this on the first take.
I need to be seen at a meeting.

693
00:51:01.000 --> 00:51:05.079
I need to be able to answer
all of these questions about how this

694
00:51:05.159 --> 00:51:07.599
particular as your component works, and
you know, I have to know this

695
00:51:07.639 --> 00:51:13.719
stuff. And that leads to a
sort of entrenched behavior when we're gathering requirements

696
00:51:14.199 --> 00:51:17.719
both in us who won't admit that
we don't know something, and it bleeds

697
00:51:17.719 --> 00:51:22.639
onto our steakholders, and they're caught
like a rabbit in the headlights. They

698
00:51:22.679 --> 00:51:24.599
have to say something or else look
like they don't know what they're doing.

699
00:51:24.639 --> 00:51:29.039
And what they say then, in
those circumstances is very often they're just making

700
00:51:29.039 --> 00:51:31.239
it up to get us to go
away. Whereas this kind of this kind

701
00:51:31.239 --> 00:51:36.199
of analysis allows us to take what
they say and stress it and push it

702
00:51:36.239 --> 00:51:40.119
around and find things outside of it
that we haven't understood. And it takes

703
00:51:40.159 --> 00:51:45.079
all that for us on the psychological
side of things. It takes a lot

704
00:51:45.119 --> 00:51:47.679
of pressure off steakholders as well,
once they realize that, you know,

705
00:51:47.800 --> 00:51:51.880
so, the question I asked to
a steakholder isn't what are your requirements?

706
00:51:51.920 --> 00:51:54.079
Anymore? It's what keeps you up
at night? What are you free it

707
00:51:54.159 --> 00:51:58.400
off? What could go wrong here? And they'll happily talk about that because

708
00:51:58.400 --> 00:52:01.239
they're under no pressure to be present
size. And the worst thing we can

709
00:52:01.239 --> 00:52:06.119
do to our stakeholders is forced them
to be precise in their language or precise

710
00:52:06.159 --> 00:52:09.360
in their description of an unknowable future. We've heard and We've heard this before

711
00:52:09.400 --> 00:52:15.239
with this, and I've certainly had
this experience that you don't interrogate like you're

712
00:52:15.239 --> 00:52:20.679
a lawyer, like you're preparing for
the lawsuit of this failed project. Let

713
00:52:20.719 --> 00:52:24.800
me get statements from you that hold
me I'm no longer liable for this thing

714
00:52:24.880 --> 00:52:30.039
failing. Yeah. I usually say
that we have a fantastic if you're a

715
00:52:30.079 --> 00:52:34.159
consultant or you know, an architectal
large company, we have a fantastic business

716
00:52:34.159 --> 00:52:37.079
model, and that is tell me
what you want, and I know it's

717
00:52:37.119 --> 00:52:40.280
wrong, and I'm going to build
it until we find out that it's wrong,

718
00:52:40.559 --> 00:52:44.119
at which point I'm going to blame
you because you didn't tell me,

719
00:52:44.159 --> 00:52:46.440
and you have to pay me a
giein to do the same thing. And

720
00:52:46.480 --> 00:52:52.199
it's this perfect business model where we
have no responsibility for what we build,

721
00:52:52.480 --> 00:52:54.599
and this is an attempt to break
out of that and change that or change

722
00:52:54.599 --> 00:52:59.599
that mold. I'm also impressed against
the idea that there's there's nothing in the

723
00:52:59.679 --> 00:53:04.639
Edge Manifesto against any of this either. Arguably, this is what real agile

724
00:53:04.920 --> 00:53:12.920
was about, was lots of communication, minimizing what you were writing, responding

725
00:53:13.000 --> 00:53:19.400
to change. It's just that it
got well folks pushed back on that sort

726
00:53:19.440 --> 00:53:23.000
of sort of agile button mindset,
right, that it keep water falling anyway.

727
00:53:23.480 --> 00:53:28.239
Yeah, I think that going back
to without getting too philosophical, but

728
00:53:28.239 --> 00:53:30.280
there was a split in our think
in three thousand years ago in Greece,

729
00:53:30.719 --> 00:53:37.480
and we chose the path of order
and structure and abstraction, and we stayed

730
00:53:37.519 --> 00:53:39.199
on that path for thousands of years. And it was good that we did

731
00:53:39.239 --> 00:53:45.239
because that gave us computers, but
it also has some weaknesses that causes us

732
00:53:45.280 --> 00:53:50.280
to think and in a particular way. When we look at social systems,

733
00:53:50.280 --> 00:53:54.320
we try to treat them like manageable
ordered machines. And the agile movement was

734
00:53:54.440 --> 00:54:00.719
actually a huge philosophical event from that
perspective because they said, hey, we

735
00:54:00.800 --> 00:54:04.119
don't know what's going on. We
can't actually write all this time. That's

736
00:54:04.159 --> 00:54:07.800
a huge philosophical step. It's a
huge challenge to our industry well, and

737
00:54:07.119 --> 00:54:12.880
arguably said can't know right, like
it is not impossible? Why should Why

738
00:54:12.960 --> 00:54:15.079
do you want us to keep lying? Right? It's sort of a pushback

739
00:54:15.079 --> 00:54:19.239
on Parnass to go, hey,
you know how we've been vaking it all

740
00:54:19.239 --> 00:54:22.760
this time? Can we just admit
we've been vaging it exactly, and that's

741
00:54:22.760 --> 00:54:28.199
why the agile movement then got suppressed. Actually, and that huge message has

742
00:54:28.239 --> 00:54:31.199
been pushed into all kinds of frameworks
and things that go back to the goal

743
00:54:31.239 --> 00:54:35.800
of giving us certainty and structure and
order. Yeah, which is I think

744
00:54:35.800 --> 00:54:39.800
against the spirit of that original manifesto. I'm not sure how many people behind

745
00:54:39.800 --> 00:54:45.360
the manifesto actually realized that they were
they were taking a swing at something really,

746
00:54:45.400 --> 00:54:50.559
really big when they said that really
big that actually swung back quite successfully.

747
00:54:51.320 --> 00:54:53.320
I remember the we talked about this
in one of the Fusion Geek outs.

748
00:54:53.400 --> 00:54:58.559
The Ider project, the giantic project
was the whole thing was get the

749
00:54:58.599 --> 00:55:02.679
first billion dollars spen because then they
can't cancel it. So we can't tell

750
00:55:04.079 --> 00:55:07.199
is what we lie until they're too
committed. Then we just work on what

751
00:55:07.320 --> 00:55:12.440
needs to be done. Yeah.
Yeah, And a number of mega projects

752
00:55:12.480 --> 00:55:15.079
that are like that, where it's
like, if you actually knew the full

753
00:55:15.119 --> 00:55:16.239
scope of this, you may not
do it, and we really want to

754
00:55:16.239 --> 00:55:20.679
do it and it will be beneficial, but we can't tell you the truth

755
00:55:20.679 --> 00:55:24.000
because then you won't do it.
Yeah, that's a great note there,

756
00:55:28.320 --> 00:55:32.000
Berry. This is so cool.
I mean You've really made my day and

757
00:55:34.280 --> 00:55:37.679
I'm loving this well, and congratulations
on what is clearly a very cool book

758
00:55:37.719 --> 00:55:40.840
which you can get for free,
but do yourself a favor at least pay

759
00:55:40.880 --> 00:55:45.039
the minimum price for you absolutely lean
pub you have a choice. Yeah,

760
00:55:45.119 --> 00:55:49.960
and it looks like a fun read. Yeah. The artwork has been done

761
00:55:50.280 --> 00:55:54.920
by my eleven year old who's incredibly
proud of it. Right, I think

762
00:55:54.920 --> 00:55:59.079
that's one of the coolest things.
And it's our project. But what's their

763
00:55:59.159 --> 00:56:02.960
name, let's call them out.
Alexander all right, who did the artwork

764
00:56:04.000 --> 00:56:12.719
and is now demanding royalties and I
like it even more. Yeah, Well,

765
00:56:12.760 --> 00:56:15.840
this is great and you've changed the
world. So thank you for spending

766
00:56:15.920 --> 00:56:20.679
the time with us today. And
well, I'm sure we're going to talk

767
00:56:20.679 --> 00:56:24.159
to you again. Cheers, guys, see you soon at a conference somewhere,

768
00:56:24.679 --> 00:56:30.079
Okay, cheers, and we'll talk
to you next time on dot net

769
00:56:30.199 --> 00:56:54.000
rocks. Dot net Rocks is brought
to you by Franklin's Net and produced by

770
00:56:54.079 --> 00:57:00.000
Pop Studios, a full service audio, video and post production facility located physically

771
00:57:00.039 --> 00:57:06.000
in New London, Connecticut, and
of course in the cloud online at pwop

772
00:57:06.239 --> 00:57:09.119
dot com. Visit our website at
d O T N E t R O

773
00:57:09.199 --> 00:57:15.480
c k S dot com for RSS
feeds, downloads, mobile apps, comments,

774
00:57:15.800 --> 00:57:19.920
and access to the full archives going
back to show number one, recorded

775
00:57:19.960 --> 00:57:22.880
in September two thousand and two.
And make sure you check out our sponsors.

776
00:57:23.039 --> 00:57:27.679
They keep us in business. Now
go write some code. See you

777
00:57:27.719 --> 00:57:37.679
next time. You got Jamtavans and