1
00:00:00,040 --> 00:00:02,920
Welcome to the Deep Dive, where 
we cut through the noise to 

2
00:00:02,920 --> 00:00:06,120
bring you the essential insights
on topics that shape our world 

3
00:00:06,600 --> 00:00:08,119
today. 
We're plunging into a subject 

4
00:00:08,119 --> 00:00:11,600
that might sound highly 
technical at first, but I 

5
00:00:11,600 --> 00:00:14,280
promise you, it's incredibly 
impactful. 

6
00:00:14,520 --> 00:00:17,160
It affects nearly every piece of
software you interact with 

7
00:00:17,320 --> 00:00:19,480
software architecture. 
These aren't just, you know, 

8
00:00:19,480 --> 00:00:22,400
obscure tech decisions. 
They are the foundational 

9
00:00:22,400 --> 00:00:25,520
choices that can truly make or 
break any system. 

10
00:00:26,280 --> 00:00:28,560
OK, let's unpack this. 
We're going to explore what 

11
00:00:28,560 --> 00:00:30,960
software architecture really 
means, look at it through 

12
00:00:30,960 --> 00:00:34,080
different lenses, understand why
these foundational choices are 

13
00:00:34,080 --> 00:00:38,720
so difficult often to reverse, 
and we'll dive into some battle 

14
00:00:38,720 --> 00:00:41,720
tested blueprints for building 
systems and even revisit a 

15
00:00:41,720 --> 00:00:44,520
legendary debate, one that 
really shows just how long the 

16
00:00:44,520 --> 00:00:47,320
shadow of an early architectural
decision can stretch. 

17
00:00:47,440 --> 00:00:50,480
That's right, our mission for 
this deep dive is well to the 

18
00:00:50,480 --> 00:00:52,760
skill the core concepts of 
software architecture. 

19
00:00:53,280 --> 00:00:55,200
We'll explore some critical 
debates, look at their 

20
00:00:55,200 --> 00:00:58,240
surprising long term outcomes, 
and ultimately help you 

21
00:00:58,240 --> 00:01:00,560
understand why these 
foundational decisions matter so

22
00:01:00,560 --> 00:01:04,239
profoundly for, well, literally 
any software system out there. 

23
00:01:04,599 --> 00:01:08,320
OK, so when we talk about 
software architecture, what 

24
00:01:08,320 --> 00:01:10,640
exactly are we referring to at 
its core? 

25
00:01:10,640 --> 00:01:14,000
Is it just high level design? 
That's a great place to start, 

26
00:01:14,000 --> 00:01:15,840
actually. 
Yeah, because high level design 

27
00:01:15,840 --> 00:01:17,640
is definitely one common way 
people think about it. 

28
00:01:17,960 --> 00:01:20,680
It means we're shifting focus, 
you know, away from the 

29
00:01:20,680 --> 00:01:24,880
individual lines of code or 
single classes to much larger 

30
00:01:24,880 --> 00:01:28,000
essential building blocks. 
Exactly. 

31
00:01:28,120 --> 00:01:30,480
Think of them as logical 
containers, ways to group 

32
00:01:30,480 --> 00:01:33,480
related code and functionality. 
It helps architects manage 

33
00:01:33,480 --> 00:01:36,320
complexity at a, well, a higher 
level. 

34
00:01:36,480 --> 00:01:38,880
Talking about things like 
packages, components, modules, 

35
00:01:38,880 --> 00:01:42,280
subsystems, layers, or services.
Honestly, the specific 

36
00:01:42,280 --> 00:01:45,480
terminology it isn't as 
important as understanding their

37
00:01:45,480 --> 00:01:47,120
significant units of 
organization. 

38
00:01:47,640 --> 00:01:51,640
OK, so these larger units, but 
what makes a particular module 

39
00:01:51,640 --> 00:01:54,720
or component architectural under
this definition you mentioned 

40
00:01:54,720 --> 00:01:56,520
essential earlier? 
Exactly. 

41
00:01:56,520 --> 00:01:59,120
Essential is the keyword there. 
Let's use an example. 

42
00:01:59,320 --> 00:02:03,400
Think about an information 
system like 1A hospital or maybe

43
00:02:03,400 --> 00:02:06,520
a bank uses a module dedicated 
to data persistence. 

44
00:02:07,080 --> 00:02:10,080
You know how data is stored and 
retrieved from a database. 

45
00:02:10,080 --> 00:02:12,000
It's absolutely essential. 
Makes sense. 

46
00:02:12,080 --> 00:02:14,680
Its core mission is managing 
information. 

47
00:02:14,680 --> 00:02:17,480
Right, so that persistence 
module is central to its 

48
00:02:17,480 --> 00:02:20,120
architecture. 
But now imagine a completely 

49
00:02:20,120 --> 00:02:23,880
different system, maybe 1 using 
AI for disease diagnosis. 

50
00:02:24,240 --> 00:02:27,440
It might also have a persistence
module, perhaps to store 

51
00:02:27,440 --> 00:02:31,240
diagnostic data. 
OK, but that module isn't 

52
00:02:31,240 --> 00:02:34,440
central to its main purpose, 
which is the diagnosis itself. 

53
00:02:35,000 --> 00:02:38,680
So while it's there, it wouldn't
be considered a key part of that

54
00:02:38,680 --> 00:02:41,320
systems architecture, not in the
same way as the first example. 

55
00:02:41,760 --> 00:02:44,160
But here's where it gets really 
interesting. 

56
00:02:44,160 --> 00:02:46,360
There's a second, even broader 
definition. 

57
00:02:46,600 --> 00:02:49,600
As Ralph Johnson famously put 
it, architecture is about the 

58
00:02:49,600 --> 00:02:51,160
important stuff, whatever that 
is. 

59
00:02:51,560 --> 00:02:54,720
I like that very direct. 
It is, and it captures the 

60
00:02:54,720 --> 00:02:58,280
essence that architecture truly 
refers to the most important 

61
00:02:58,280 --> 00:03:00,920
design decisions in a system. 
So important. 

62
00:03:00,920 --> 00:03:03,840
What makes these decisions so 
important they count as 

63
00:03:03,840 --> 00:03:05,760
architecture? 
Is it just their scale? 

64
00:03:06,240 --> 00:03:08,160
It's not just scale, though 
that's often part of it. 

65
00:03:08,360 --> 00:03:11,360
It's their fundamental nature. 
The crucial aspect is this. 

66
00:03:11,920 --> 00:03:15,120
Once these decisions are made, 
they are incredibly difficult to

67
00:03:15,120 --> 00:03:18,640
revert. 
OK, so hard to undo. 

68
00:03:18,880 --> 00:03:21,280
Extremely hard. 
Think of it like laying the 

69
00:03:21,280 --> 00:03:24,040
foundation for a house. 
You can change the paint color 

70
00:03:24,040 --> 00:03:27,280
later, maybe add a room, But 
completely redesigning the 

71
00:03:27,280 --> 00:03:28,920
foundation after the house is 
built? 

72
00:03:29,280 --> 00:03:32,880
That's a monumental task, often 
just impossible, practically 

73
00:03:32,880 --> 00:03:33,960
speaking. 
Right I. 

74
00:03:34,360 --> 00:03:35,720
See, and. 
This definition is more general 

75
00:03:35,720 --> 00:03:38,160
because it's not just about the 
modules, the building blocks. 

76
00:03:38,640 --> 00:03:41,400
It covers fundamental choices 
like, yes, defining the main 

77
00:03:41,400 --> 00:03:44,880
modules, but also critical 
decisions like the choice of 

78
00:03:44,880 --> 00:03:47,600
programming language. 
Oh yeah, that's a big one. 

79
00:03:47,720 --> 00:03:51,600
Huge, or the specific database 
the system relies on. 

80
00:03:52,000 --> 00:03:54,760
Once you've built an entire 
system on, say, a particular 

81
00:03:54,760 --> 00:03:58,240
database, or written millions of
lines of code in a specific 

82
00:03:58,240 --> 00:04:01,520
language migrating to a 
different one, it's an 

83
00:04:01,520 --> 00:04:04,120
engineering Everest. 
We're locked in to some extent. 

84
00:04:04,120 --> 00:04:08,240
Exactly, that's why even today 
you can find critical large 

85
00:04:08,240 --> 00:04:12,520
scale systems still running on 
non relational databases or even

86
00:04:12,520 --> 00:04:14,600
implemented in very old 
languages like COBOL. 

87
00:04:15,360 --> 00:04:17,760
These are the long shadows of 
those early architectural 

88
00:04:17,760 --> 00:04:20,480
decisions, really proving how 
irreversible they can be. 

89
00:04:20,720 --> 00:04:23,520
Wow. 
O If these fundamental decisions

90
00:04:23,520 --> 00:04:28,360
are so critical and so hard to 
change, how do architects even 

91
00:04:28,360 --> 00:04:30,800
begin? 
How do they approach designing 

92
00:04:30,800 --> 00:04:32,720
these complex systems? 
They don't just start from a 

93
00:04:32,720 --> 00:04:34,640
blank slate every time, surely? 
Precisely. 

94
00:04:34,880 --> 00:04:37,160
No, they don't. 
And that brings us neatly to 

95
00:04:37,160 --> 00:04:39,640
architectural patterns. 
These are essentially, you know,

96
00:04:39,800 --> 00:04:42,400
battle tested blueprints. 
They propose a high level 

97
00:04:42,400 --> 00:04:43,920
organization for software 
systems. 

98
00:04:43,920 --> 00:04:47,080
They layout the key modules and 
define how they relate to each 

99
00:04:47,080 --> 00:04:49,200
other. 
Like can module A talk directly 

100
00:04:49,200 --> 00:04:50,720
to module B? 
Things like that. 

101
00:04:51,000 --> 00:04:54,200
They represent the accumulated 
wisdom of experienced architects

102
00:04:54,200 --> 00:04:56,480
offering solutions to common 
structural challenges. 

103
00:04:56,480 --> 00:04:59,440
So they're like recipes for 
different kinds of software 

104
00:04:59,440 --> 00:05:01,600
problems. 
You can definitely say that they

105
00:05:01,600 --> 00:05:06,240
previewed a common language and 
a starting point for solving 

106
00:05:06,240 --> 00:05:09,360
recurring problems. 
The sources for this deep dive 

107
00:05:09,360 --> 00:05:11,920
mention a range of these 
patterns, each offering 

108
00:05:11,920 --> 00:05:14,960
different structural approaches.
For instance, concepts like 

109
00:05:14,960 --> 00:05:18,600
layered architecture, which 
separates an application into 

110
00:05:18,600 --> 00:05:22,840
distinct logical tiers, or Model
View controller, often called 

111
00:05:22,840 --> 00:05:26,880
MVC designed to untangle data, 
user interface and logic, 

112
00:05:27,040 --> 00:05:28,800
especially in graphical 
applications. 

113
00:05:28,880 --> 00:05:31,000
Right, I've heard of MVC. 
Very common. 

114
00:05:31,280 --> 00:05:33,760
Then there are things like 
microservices, which breaks down

115
00:05:33,760 --> 00:05:36,600
large systems into small, 
independently deployable 

116
00:05:36,600 --> 00:05:38,520
services. 
That gives you incredible 

117
00:05:38,520 --> 00:05:40,000
agility and resilience. 
That's a. 

118
00:05:40,040 --> 00:05:42,400
Big trend now, isn't it huge? 
Yeah, absolutely. 

119
00:05:42,680 --> 00:05:46,040
There's also Message Oriented 
architecture, Publish, subscribe

120
00:05:46,040 --> 00:05:48,080
architecture and other patterns 
like pipes and filters. 

121
00:05:48,080 --> 00:05:49,320
Lots of tools in the toolbox 
and. 

122
00:05:49,320 --> 00:05:52,040
I think I heard of one that 
sounds less like a solution and 

123
00:05:52,040 --> 00:05:54,760
more like a warning sign. 
The big ball of mud. 

124
00:05:54,880 --> 00:05:57,840
Indeed, that's the one. 
It's an architectural anti 

125
00:05:57,840 --> 00:05:59,840
pattern. 
It crops up when things go 

126
00:05:59,840 --> 00:06:02,760
wrong. 
It's kind of a humorous name for

127
00:06:02,760 --> 00:06:05,280
a system that lacks any 
discernible architecture, where 

128
00:06:05,280 --> 00:06:07,240
everything is tangled and 
interdependent. 

129
00:06:07,440 --> 00:06:10,360
The nightmare scenario. 
Pretty much it's what happens 

130
00:06:10,360 --> 00:06:12,920
when you don't follow a pattern,
or maybe when a pattern breaks 

131
00:06:12,920 --> 00:06:16,880
down over time under changes. 
It's worth noting A nuanced 

132
00:06:16,880 --> 00:06:20,120
point here to Some authors 
differentiate between pattern 

133
00:06:20,120 --> 00:06:23,720
solutions to specific problems 
and architectural styles, which 

134
00:06:23,720 --> 00:06:26,400
propose a more general way to 
organize modules. 

135
00:06:27,080 --> 00:06:29,800
But for our purposes in this 
deep dive, we're treating them 

136
00:06:29,800 --> 00:06:32,520
all under the umbrella term of 
architectural patterns. 

137
00:06:32,520 --> 00:06:34,800
They all offer structured 
approaches to design. 

138
00:06:34,920 --> 00:06:37,840
OK, that makes sense. 
And that brings us perfectly to 

139
00:06:37,880 --> 00:06:41,160
a real world case study, one 
that brilliantly illustrates the

140
00:06:41,160 --> 00:06:43,320
long term impact of these 
decisions. 

141
00:06:43,360 --> 00:06:46,680
You know, for better or worse. 
It's known as the Tannenbaum 

142
00:06:46,680 --> 00:06:50,400
Torvalds debate, a really heated
exchange that erupted back in 

143
00:06:50,400 --> 00:06:53,120
early 1992 in an Internet 
discussion forum. 

144
00:06:53,120 --> 00:06:55,400
Oh yeah, legendary stuff. 
Absolutely. 

145
00:06:55,400 --> 00:06:57,800
On one side, you've had Andrew 
Tannenbaum, A respected 

146
00:06:57,800 --> 00:07:00,360
researcher, textbook author, 
professor, and operating 

147
00:07:00,360 --> 00:07:02,880
systems. 
On the other, a then computer 

148
00:07:02,880 --> 00:07:05,160
science student named Linus 
Torvalds. 

149
00:07:05,880 --> 00:07:06,920
She was a student at the time, 
yeah. 

150
00:07:07,120 --> 00:07:10,320
The whole thing kicked off when 
Panenbaum posted a message with 

151
00:07:10,480 --> 00:07:13,120
the provocative title Linux is 
Obsolete. 

152
00:07:14,440 --> 00:07:17,200
His core argument was that Linux
followed A monolithic 

153
00:07:17,200 --> 00:07:20,480
architecture, which meant all 
the operating system functions, 

154
00:07:20,480 --> 00:07:24,160
managing processes, memory, file
systems, everything were bundled

155
00:07:24,160 --> 00:07:27,320
into a single executable file 
running in what's called 

156
00:07:27,320 --> 00:07:30,160
supervisor mode. 
Right, and that supervisor mode 

157
00:07:30,160 --> 00:07:33,800
meant it had direct, unfiltered 
access to the computer score 

158
00:07:33,800 --> 00:07:36,840
hardware. 
Very powerful, but potentially 

159
00:07:36,840 --> 00:07:38,560
risky, at least in Tannenbaum's 
view. 

160
00:07:38,920 --> 00:07:41,760
He was a strong advocate for the
opposite, a micro kernel 

161
00:07:41,760 --> 00:07:43,120
architecture. 
OK, what's the difference there?

162
00:07:43,120 --> 00:07:45,760
In the micro kernel approach, 
the kernel, the absolute core of

163
00:07:45,760 --> 00:07:48,120
the OS, handles only the most 
basic system functions, 

164
00:07:48,360 --> 00:07:50,640
minimalist. 
Everything else, like device 

165
00:07:50,640 --> 00:07:54,520
drivers, file systems, network 
stacks, they run as independent 

166
00:07:54,520 --> 00:07:56,760
processes outside the kernel. 
Isolated. 

167
00:07:57,280 --> 00:08:01,320
Safer theoretically. 
So Tannenbaum saw monolithic as 

168
00:08:01,360 --> 00:08:04,680
old fashioned and risky 
microkernel as the future. 

169
00:08:04,680 --> 00:08:06,600
That was his argument. 
And Torvalds? 

170
00:08:07,600 --> 00:08:09,800
Well, he didn't take that 
critique lightly. 

171
00:08:10,200 --> 00:08:12,240
He responded pretty 
emphatically. 

172
00:08:12,600 --> 00:08:15,880
He basically asserted that Linux
was a practical working 

173
00:08:15,880 --> 00:08:19,320
operating system right then, 
while the micro kernel system 

174
00:08:19,320 --> 00:08:23,160
Tannenbaum was developing was, 
in his words, facing various 

175
00:08:23,160 --> 00:08:25,920
problems and bugs. 
He got quite pointed the 

176
00:08:25,920 --> 00:08:27,640
practical versus the 
theoretical. 

177
00:08:27,800 --> 00:08:30,480
Yeah, Tannenbaum even quipped 
that if Torvalds had been his 

178
00:08:30,480 --> 00:08:33,480
student, he'd have gotten a poor
grade for the monolithic Linux 

179
00:08:33,480 --> 00:08:34,880
architecture. 
Ouch. 

180
00:08:35,240 --> 00:08:38,559
A classic academic versus 
practitioner in their clash in 

181
00:08:38,559 --> 00:08:39,679
many ways. 
Definitely. 

182
00:08:39,880 --> 00:08:43,640
And you know, if we connect this
to the bigger picture, there was

183
00:08:43,640 --> 00:08:46,360
an incredibly insightful comment
from Ken Thompson. 

184
00:08:46,480 --> 00:08:49,320
Oh, the Eunice Pioneer. 
The very same, Yeah, he weighed 

185
00:08:49,320 --> 00:08:52,080
in on the debate and he observed
something really key. 

186
00:08:52,080 --> 00:08:53,840
He said. 
It is, in my opinion, easier to 

187
00:08:53,840 --> 00:08:57,000
implement a monolithic kernel. 
It is also easier for it to turn

188
00:08:57,000 --> 00:08:59,040
into a mess in a hurry as it is 
modified. 

189
00:08:59,160 --> 00:09:01,080
Wow, that's. 
Quite a statement. 

190
00:09:01,080 --> 00:09:03,080
Easier to start, easier to mess 
up. 

191
00:09:03,280 --> 00:09:05,280
Exactly. 
It just encapsulates that core 

192
00:09:05,280 --> 00:09:08,160
architectural challenge so well.
The path etheles resistance. 

193
00:09:08,160 --> 00:09:11,720
The easier initial choice often 
leads to the biggest problems 

194
00:09:11,720 --> 00:09:13,400
down the road as the system 
evolves. 

195
00:09:13,560 --> 00:09:15,200
And here's where it gets really 
interesting. 

196
00:09:15,200 --> 00:09:16,480
Almost like Thompson predicted 
it. 

197
00:09:16,720 --> 00:09:23,120
Fast forward 17 years to 2009. 
Linus Torvalds himself, speaking

198
00:09:23,120 --> 00:09:26,160
at a conference, made a pretty 
dramatic declaration. 

199
00:09:26,160 --> 00:09:29,360
He said, and I'm quoting here, 
We are definitely not the 

200
00:09:29,360 --> 00:09:32,200
streamlined, small, hyper 
efficient kernel that I 

201
00:09:32,200 --> 00:09:35,880
envisioned 15 years ago. 
The kernel is huge and bloated. 

202
00:09:35,920 --> 00:09:37,800
Wow. 
From the man himself. 

203
00:09:37,800 --> 00:09:40,440
Right, he continued. 
And whenever we add a new 

204
00:09:40,440 --> 00:09:43,560
feature, it only gets worse. 
That comment was widely 

205
00:09:43,560 --> 00:09:45,040
reported. 
You can find it all over 

206
00:09:45,040 --> 00:09:46,000
Wikipedia. 
Has it? 

207
00:09:46,000 --> 00:09:48,480
It really resonated. 
So what does this all mean? 

208
00:09:48,480 --> 00:09:51,200
What's the take away here? 
The profound lesson from this 

209
00:09:51,200 --> 00:09:54,080
whole Tannenbaum Torvalds 
debate, I think, is crystal 

210
00:09:54,080 --> 00:09:56,280
clear. 
Architectural decisions are not 

211
00:09:56,280 --> 00:09:59,240
only incredibly important and 
difficult to reverse, but 

212
00:09:59,240 --> 00:10:02,400
they're negative consequences 
can take years, sometimes even 

213
00:10:02,400 --> 00:10:05,200
decades, to really become 
apparent and start causing 

214
00:10:05,200 --> 00:10:08,040
serious problems. 
So that initial choice back in 

215
00:10:08,040 --> 00:10:12,240
92 still having repercussions in
2009 and beyond? 

216
00:10:12,280 --> 00:10:14,400
Absolutely. 
It's a stark reminder, isn't it?

217
00:10:14,680 --> 00:10:17,440
Getting that architecture right,
or at least making informed 

218
00:10:17,440 --> 00:10:21,600
choices early on can prevent 
massive headaches and, well, 

219
00:10:21,680 --> 00:10:24,400
bloat down the line. 
It affects the long term health,

220
00:10:24,560 --> 00:10:27,560
the efficiency, the 
maintainability of any software 

221
00:10:27,560 --> 00:10:29,520
system. 
It really highlights why those 

222
00:10:29,520 --> 00:10:32,280
initial, sometimes seemingly 
abstract choices about the 

223
00:10:32,280 --> 00:10:35,000
important stuff are actually the
most critical ones you can make 

224
00:10:35,000 --> 00:10:37,520
in the long run. 
A fascinating look at how deep 

225
00:10:37,520 --> 00:10:40,240
these technical decisions run. 
Thank you for joining us on this

226
00:10:40,240 --> 00:10:41,800
deep dive into software 
architecture. 

227
00:10:41,800 --> 00:10:42,920
Thank you, it was a pleasure.