1
00:00:00,040 --> 00:00:03,000
Welcome to the deep dive. 
Today we're jumping into 

2
00:00:03,000 --> 00:00:05,200
something really core to 
software development 

3
00:00:05,640 --> 00:00:07,600
refactoring. 
Yeah, it's one of those terms 

4
00:00:07,600 --> 00:00:09,400
you hear a lot, but what does it
really mean? 

5
00:00:09,400 --> 00:00:11,880
Exactly. 
It's absolutely fundamental for 

6
00:00:11,880 --> 00:00:15,400
keeping software healthy, 
adaptable, you know, usable over

7
00:00:15,400 --> 00:00:17,960
time. 
So our mission for you today is 

8
00:00:17,960 --> 00:00:20,360
to unpack it. 
What is refactoring? 

9
00:00:20,480 --> 00:00:23,080
Why is it so vital? 
And actually, where did this 

10
00:00:23,080 --> 00:00:26,200
whole idea come from? 
We're digging into Marco Tulio 

11
00:00:26,200 --> 00:00:30,680
Valente's Software Engineering a
Modern Approach, specifically 

12
00:00:30,680 --> 00:00:32,759
Chapter 9. 
Right, we'll pull out the key 

13
00:00:32,759 --> 00:00:35,480
ideas, maybe some surprising 
bits so you can get up to speed 

14
00:00:35,480 --> 00:00:38,320
fast on this really essential 
concept. 

15
00:00:38,480 --> 00:00:40,560
Sounds good. 
OK, so let's start with the 

16
00:00:40,560 --> 00:00:42,840
basics. 
If software is always being 

17
00:00:42,840 --> 00:00:47,240
worked on, new features, bug 
fixes, why do we need this 

18
00:00:47,240 --> 00:00:49,040
separate thing called 
refactoring? 

19
00:00:49,040 --> 00:00:50,600
Isn't building and fixing 
enough? 

20
00:00:51,040 --> 00:00:52,600
Well, that's a really good 
starting point, because 

21
00:00:52,600 --> 00:00:56,440
refactoring is it directly 
connected to the fact that 

22
00:00:56,440 --> 00:00:59,800
software isn't static. 
It lives, it changes, it 

23
00:00:59,800 --> 00:01:03,040
constantly needs maintenance. 
Just like, well, any complex 

24
00:01:03,040 --> 00:01:04,720
system, right? 
And the source material breaks 

25
00:01:04,720 --> 00:01:06,160
this down. 
There's corrective maintenance. 

26
00:01:06,440 --> 00:01:08,760
OK, so fixing bugs basically. 
Exactly. 

27
00:01:08,760 --> 00:01:11,600
Defects pop up, you fix them, 
then there's evolutionary 

28
00:01:11,600 --> 00:01:13,920
maintenance. 
Adding new features, making it 

29
00:01:13,920 --> 00:01:16,480
do more stuff. 
Yep, meeting new user needs. 

30
00:01:16,680 --> 00:01:18,880
And finally, there's adaptive 
maintenance. 

31
00:01:18,960 --> 00:01:20,680
Adaptive. 
What's that cover? 

32
00:01:20,960 --> 00:01:22,920
That's about keeping up with the
outside world. 

33
00:01:22,960 --> 00:01:25,320
Yeah. 
So changes in the the OS, new 

34
00:01:25,320 --> 00:01:28,400
business rules, different 
hardware, maybe the environment 

35
00:01:28,400 --> 00:01:30,360
changes, the software has to 
adapt. 

36
00:01:30,400 --> 00:01:32,320
Got it. 
So corrective evolutionary 

37
00:01:32,320 --> 00:01:34,640
adaptive standard maintenance 
but. 

38
00:01:34,640 --> 00:01:36,840
Here's where it gets 
interesting, and maybe a bit 

39
00:01:36,840 --> 00:01:38,840
unexpected. 
Software systems. 

40
00:01:39,560 --> 00:01:42,280
They actually age. 
Age like physically? 

41
00:01:42,560 --> 00:01:46,600
No, not like rust on metal. 
But functionally, structurally. 

42
00:01:46,920 --> 00:01:50,280
It's a concept that Mir Lehman 
studied way back in their early 

43
00:01:50,280 --> 00:01:52,520
70s at IBM. 
The 70s. 

44
00:01:52,680 --> 00:01:54,200
Wow. 
Yeah, His work led to what we 

45
00:01:54,200 --> 00:01:57,160
call the software evolution 
loss, or just Lehman's loss, and

46
00:01:57,160 --> 00:01:59,200
he really changed how we think 
about software over its 

47
00:01:59,200 --> 00:02:00,680
lifespan. 
OK, Lehman's laws. 

48
00:02:00,720 --> 00:02:04,680
So what did these laws tell us? 
How do they connect to 

49
00:02:04,680 --> 00:02:07,560
refactoring needing to exist? 
Well, the first law is pretty 

50
00:02:07,560 --> 00:02:10,080
fundamental. 
It basically says a system must 

51
00:02:10,080 --> 00:02:12,320
be continuously adapted to its 
environment. 

52
00:02:12,680 --> 00:02:14,160
Right. 
Like that adaptive maintenance 

53
00:02:14,160 --> 00:02:15,120
you mentioned. 
Exactly. 

54
00:02:15,160 --> 00:02:17,320
It had to keep up or becomes 
useless. 

55
00:02:17,320 --> 00:02:20,920
Yeah, and the law continues 
saying this adaptation goes on 

56
00:02:21,240 --> 00:02:23,520
until it becomes more 
advantageous to replace the 

57
00:02:23,520 --> 00:02:24,960
system with a new one. 
Ouch. 

58
00:02:25,720 --> 00:02:29,920
So systems can essentially die 
or just get too expensive to 

59
00:02:29,920 --> 00:02:31,200
keep alive. 
Pretty much. 

60
00:02:31,240 --> 00:02:34,640
It acknowledges that reality, 
but it's the second law that 

61
00:02:34,640 --> 00:02:36,320
really hits home for 
refactoring. 

62
00:02:36,320 --> 00:02:39,960
OK, what's the second law? 
It states as a system undergoes 

63
00:02:39,960 --> 00:02:44,040
maintenance, its internal 
complexity increases unless 

64
00:02:44,040 --> 00:02:46,920
deliberate efforts are made to 
reduce this complexity. 

65
00:02:47,760 --> 00:02:51,400
OK, so just doing maintenance, 
even the good kinds like adding 

66
00:02:51,400 --> 00:02:55,440
features, naturally makes the 
code messier, more complicated 

67
00:02:55,440 --> 00:02:56,640
inside. 
Precisely. 

68
00:02:56,800 --> 00:02:59,120
Every time you touch it, you 
risk adding a little more 

69
00:02:59,120 --> 00:03:00,800
complexity, a bit more 
entanglement. 

70
00:03:01,040 --> 00:03:03,600
Overtime it just gets harder and
harder to understand, harder to 

71
00:03:03,600 --> 00:03:05,520
change safely. 
That sounds like the technical 

72
00:03:05,520 --> 00:03:07,440
dead everyone dreads. 
It just creeps in. 

73
00:03:07,640 --> 00:03:11,040
That's a perfect way to put it. 
It's this slow, often invisible 

74
00:03:11,040 --> 00:03:14,440
degradation of internal quality.
But, and this is the crucial 

75
00:03:14,440 --> 00:03:17,720
part, that caveat in the law, 
this deterioration can be 

76
00:03:17,720 --> 00:03:21,040
prevented. 
It says it right there unless 

77
00:03:21,040 --> 00:03:24,400
deliberate efforts are made to 
reduce this complexity. 

78
00:03:25,360 --> 00:03:28,360
So that's the connection, that 
deliberate effort, that specific

79
00:03:28,360 --> 00:03:30,200
work to fight the complexity 
creep. 

80
00:03:30,520 --> 00:03:32,520
That's what we call refactoring 
today. 

81
00:03:32,520 --> 00:03:34,440
You nailed it. 
That's exactly the why. 

82
00:03:34,800 --> 00:03:38,640
It's the counterbalance to the 
natural decay caused by ongoing 

83
00:03:38,640 --> 00:03:40,960
maintenance. 
OK, so if that's why we need it 

84
00:03:41,320 --> 00:03:44,520
to fight this inevitable 
complexity, what is refactoring?

85
00:03:44,520 --> 00:03:47,120
What's the actual definition 
according to the source nailed 

86
00:03:47,120 --> 00:03:49,480
down for us? 
The book gives a very precise 

87
00:03:49,480 --> 00:03:52,160
definition. 
It says refactorings are code 

88
00:03:52,160 --> 00:03:55,520
transformations that improve a 
system's maintainability without

89
00:03:55,520 --> 00:03:58,720
affecting its behavior. 
OK, code transformations improve

90
00:03:58,720 --> 00:04:01,480
maintainability without 
affecting behavior. 

91
00:04:01,640 --> 00:04:03,600
Let's unpack that. 
What are code transformations? 

92
00:04:03,720 --> 00:04:05,920
Right, so this means you're 
actually changing the source 

93
00:04:05,920 --> 00:04:08,720
code, making modifications. 
And these aren't just tiny 

94
00:04:08,720 --> 00:04:10,000
tweaks. 
Usually the source gives 

95
00:04:10,000 --> 00:04:14,120
examples like splitting a big 
complex function into two 

96
00:04:14,120 --> 00:04:16,279
smaller, more focused ones. 
Makes sense, easier to 

97
00:04:16,279 --> 00:04:20,680
understand smaller pieces. 
Or renaming A variable so it's 

98
00:04:20,680 --> 00:04:24,800
purpose is crystal clear. 
Or maybe moving a function from 

99
00:04:24,800 --> 00:04:27,120
one class to another where it 
fits better logically, 

100
00:04:27,360 --> 00:04:29,320
extracting an interface from a 
class. 

101
00:04:29,760 --> 00:04:31,640
Things like that. 
Structural changes. 

102
00:04:31,720 --> 00:04:33,440
OK, changing the code structure.
Got it. 

103
00:04:33,960 --> 00:04:36,680
Second part, improve 
maintainability. 

104
00:04:37,520 --> 00:04:40,280
What does that mean in practice 
for, you know, the developer? 

105
00:04:41,000 --> 00:04:44,480
Maintainability is really about 
making the code easier to live 

106
00:04:44,480 --> 00:04:46,160
with and evolve over the long 
haul. 

107
00:04:46,560 --> 00:04:49,960
So improving maintainability 
could mean making the code more 

108
00:04:49,960 --> 00:04:52,280
modular, better separation 
between different parts. 

109
00:04:52,680 --> 00:04:55,280
It could mean improving the 
overall design or architecture. 

110
00:04:55,280 --> 00:04:57,080
Making it cleaner, more 
organized. 

111
00:04:57,080 --> 00:04:58,800
Exactly. 
Cleaner, more organized. 

112
00:04:59,240 --> 00:05:03,000
It also often means making the 
code easier to test, and 

113
00:05:03,000 --> 00:05:04,880
crucially, making it more 
readable. 

114
00:05:04,880 --> 00:05:07,520
Just easier for humans to 
understand and modify later 

115
00:05:07,640 --> 00:05:10,320
without breaking things or 
spending ages figuring it out, 

116
00:05:10,640 --> 00:05:13,640
reducing that cognitive load. 
Right, so future you or your 

117
00:05:13,640 --> 00:05:15,560
teammate doesn't curse your 
name. 

118
00:05:15,560 --> 00:05:17,160
Pretty much. 
And that leads to the third 

119
00:05:17,160 --> 00:05:19,920
part, which is absolutely vital.
Without affecting its behavior, 

120
00:05:20,120 --> 00:05:23,920
this sounds like the tricky bit.
It is the absolute rule, the non

121
00:05:23,920 --> 00:05:27,200
negotiable constraint. 
It means while you're busy 

122
00:05:27,280 --> 00:05:30,720
tidying up the insides, making 
the code better structured, more

123
00:05:30,720 --> 00:05:35,440
maintainable, the program must 
still work exactly the same way 

124
00:05:35,440 --> 00:05:38,800
from the outside. 
So the user sees no difference. 

125
00:05:38,840 --> 00:05:42,680
None whatsoever. 
The results, the functionality, 

126
00:05:42,680 --> 00:05:45,960
everything the user interacts 
with has to remain identical. 

127
00:05:46,560 --> 00:05:49,600
The source puts it bluntly. 
It is not worth improving 

128
00:05:49,600 --> 00:05:52,520
maintainability at the cost of 
changing the program's results. 

129
00:05:53,280 --> 00:05:55,640
Refactoring must preserve 
behavior. 

130
00:05:55,800 --> 00:05:57,240
That's a really strong 
constraint. 

131
00:05:57,240 --> 00:05:59,600
It makes sense though. 
You don't want to clean up by 

132
00:05:59,600 --> 00:06:02,040
breaking things. 
I like that library analogy you 

133
00:06:02,040 --> 00:06:04,240
hinted at earlier. 
It's like reorganizing all your 

134
00:06:04,240 --> 00:06:07,320
bookshelves, maybe grouping by 
genre, alphabetizing. 

135
00:06:07,800 --> 00:06:10,360
You make it much easier to find 
books later, easier to add new 

136
00:06:10,360 --> 00:06:12,000
ones. 
But you haven't rewritten any 

137
00:06:12,000 --> 00:06:14,760
chapters or changed the stories 
inside the books themselves. 

138
00:06:14,960 --> 00:06:16,960
The content and function are 
preserved. 

139
00:06:17,080 --> 00:06:19,560
That's a perfect analogy. 
You improve the internal 

140
00:06:19,560 --> 00:06:22,040
organization without altering 
the external purpose or 

141
00:06:22,040 --> 00:06:24,280
function. 
That's factoring in a nutshell. 

142
00:06:24,320 --> 00:06:26,640
OK, that really clarifies it 
now. 

143
00:06:26,640 --> 00:06:30,040
It's interesting you mentioned 
Lehman's laws are from the 70s, 

144
00:06:30,040 --> 00:06:32,360
so the idea of fighting 
complexity isn't new. 

145
00:06:32,720 --> 00:06:36,240
But the term refactoring itself 
wasn't really used then, right? 

146
00:06:36,520 --> 00:06:38,480
When did that specific word pop 
up? 

147
00:06:38,880 --> 00:06:41,880
That's right, the concept was 
understood, or at least grappled

148
00:06:41,880 --> 00:06:44,400
with, but the specific term is 
much more recent. 

149
00:06:45,000 --> 00:06:48,520
The source points to one of the 
first documented uses being in 

150
00:06:48,520 --> 00:06:52,200
1992. 92. 
Yeah, in a doctoral thesis by a 

151
00:06:52,200 --> 00:06:55,000
researcher named William Opdyke 
at the University of Illinois. 

152
00:06:55,440 --> 00:06:58,280
So the formal naming came quite 
a bit later than the initial 

153
00:06:58,280 --> 00:07:01,440
understanding of the problem. 
And how did it go from a thesis 

154
00:07:01,440 --> 00:07:04,320
term to, well, something 
developers actually talk about 

155
00:07:04,320 --> 00:07:06,480
and do? 
A big step was its integration 

156
00:07:06,480 --> 00:07:10,560
into programming methodologies. 
In 1999, refactoring was 

157
00:07:10,560 --> 00:07:13,160
officially included as one of 
the core practices in Extreme 

158
00:07:13,160 --> 00:07:17,560
Programming, or XP. 
XP agile methods really pushed 

159
00:07:17,560 --> 00:07:18,600
this then. 
Absolutely. 

160
00:07:18,840 --> 00:07:21,520
XP explicitly recommended the 
developers should be doing 

161
00:07:21,520 --> 00:07:24,080
refactorings regularly. 
Like all the time. 

162
00:07:24,320 --> 00:07:26,960
Their reasoning was to 
restructure systems, yes, but 

163
00:07:26,960 --> 00:07:29,560
also things like removing code 
duplication, improving 

164
00:07:29,560 --> 00:07:31,080
communication between 
developers. 

165
00:07:31,280 --> 00:07:33,520
How does refactoring improve 
communication? 

166
00:07:34,000 --> 00:07:37,320
Well, clearer, better structured
code is just easier to talk 

167
00:07:37,320 --> 00:07:39,000
about, right? 
Easier for the whole team to 

168
00:07:39,000 --> 00:07:42,480
understand, to collaborate on. 
Also stressed using it to 

169
00:07:42,480 --> 00:07:45,840
simplify the design or make it 
more flexible for future 

170
00:07:45,840 --> 00:07:48,200
changes. 
Directly addressing Lehman's 

171
00:07:48,200 --> 00:07:49,280
second law? 
Really. 

172
00:07:49,680 --> 00:07:53,040
So XP embedded it as a practice,
but what really made it 

173
00:07:53,040 --> 00:07:55,240
mainstream? 
That really happened in 2000 

174
00:07:55,480 --> 00:07:58,080
with Martin Fowler's book. 
The 1st edition of his book 

175
00:07:58,080 --> 00:08:00,360
specifically on refactoring. 
That was a game changer. 

176
00:08:00,360 --> 00:08:02,160
Fowler's book. 
I've definitely heard of that 

177
00:08:02,160 --> 00:08:03,720
one. 
Why was it so influential? 

178
00:08:03,800 --> 00:08:05,600
Several reasons, according to 
our source. 

179
00:08:05,680 --> 00:08:09,480
A huge one was that it presented
this big cattle log of dozens of

180
00:08:09,480 --> 00:08:12,920
specific refactorings, and 
crucially, it named them. 

181
00:08:13,480 --> 00:08:16,880
Like design patterns, giving 
things names creates a shared 

182
00:08:16,880 --> 00:08:17,960
vocabulary. 
Exactly. 

183
00:08:18,080 --> 00:08:19,960
Suddenly developers had a common
language. 

184
00:08:20,080 --> 00:08:23,960
They can say let's apply extract
method here, or this needs the 

185
00:08:23,960 --> 00:08:27,520
rename variable refactoring. 
It wasn't just vague cleaning up

186
00:08:27,520 --> 00:08:28,920
anymore. 
It made it concrete. 

187
00:08:29,080 --> 00:08:31,040
Totally. 
And the book didn't just list 

188
00:08:31,040 --> 00:08:32,799
them. 
It detailed the mechanics, how 

189
00:08:32,799 --> 00:08:35,919
to perform each one safely. 
It gave code examples. 

190
00:08:36,120 --> 00:08:39,159
It discussed the benefits, but 
also the potential drawbacks or 

191
00:08:39,159 --> 00:08:42,080
trade-offs. 
It basically turned refactoring 

192
00:08:42,320 --> 00:08:46,200
from an abstract ideal into a 
practical, reputable discipline.

193
00:08:46,240 --> 00:08:48,880
It democratized it. 
Making it accessible not just 

194
00:08:48,880 --> 00:08:50,080
for gurus. 
Right. 

195
00:08:50,720 --> 00:08:53,520
And Fowler really leaned into 
this idea of good habits. 

196
00:08:53,520 --> 00:08:57,360
He highlighted a quote from Kent
Beck, another key figure in XP, 

197
00:08:57,360 --> 00:08:59,320
which actually opens the chapter
we're looking at. 

198
00:08:59,400 --> 00:09:01,720
What's the quote? 
It's I'm not a great programmer.

199
00:09:01,720 --> 00:09:03,840
I'm just a good programmer with 
great habits. 

200
00:09:03,880 --> 00:09:06,360
I like that It's not about 
genius, it's about discipline. 

201
00:09:06,600 --> 00:09:09,200
Precisely. 
Fowler used that to emphasize 

202
00:09:09,200 --> 00:09:12,360
that refactoring isn't some 
heroic one off effort. 

203
00:09:12,760 --> 00:09:16,200
It's part of the steady, 
disciplined good habits needed 

204
00:09:16,200 --> 00:09:18,240
to keep software healthy over 
the long term. 

205
00:09:18,760 --> 00:09:21,960
It reinforces that developers 
need to do more than just fix 

206
00:09:21,960 --> 00:09:25,280
bugs and add features that 
corrective adaptive evolutionary

207
00:09:25,280 --> 00:09:27,840
stuff we talked about. 
They also need to weave in 

208
00:09:27,840 --> 00:09:29,960
frequent refactoring as a 
regular practice. 

209
00:09:29,960 --> 00:09:31,520
Like brushing your teeth for 
your code. 

210
00:09:31,840 --> 00:09:34,080
Proactive hygiene. 
That's a great way to think 

211
00:09:34,080 --> 00:09:36,520
about it. 
It prevents the decay the build 

212
00:09:36,520 --> 00:09:40,000
up of that technical debt. 
Teams that make it a habit tend 

213
00:09:40,000 --> 00:09:43,760
to maintain velocity, while 
teams that neglect it slow down 

214
00:09:43,760 --> 00:09:46,720
as the code base gets messier 
and riskier to change. 

215
00:09:47,000 --> 00:09:50,040
So it's a shift from just 
reacting to problems to 

216
00:09:50,040 --> 00:09:51,880
proactively maintaining the 
codes. 

217
00:09:51,880 --> 00:09:54,320
Health and adaptability makes 
total sense. 

218
00:09:54,320 --> 00:09:56,440
Exactly. 
Now there's one more point of 

219
00:09:56,440 --> 00:10:00,320
clarification the source makes, 
which is important because the 

220
00:10:00,320 --> 00:10:03,280
term refactoring gets thrown 
around a bit loosely sometimes. 

221
00:10:04,160 --> 00:10:06,280
How so? 
Well, you'll hear develoers talk

222
00:10:06,280 --> 00:10:09,520
about refactoring for 
performance, or refactoring to 

223
00:10:09,520 --> 00:10:13,400
add concurrency, or maybe even 
refactoring the UI for better 

224
00:10:13,400 --> 00:10:15,280
usability. 
Right, I think I've heard that 

225
00:10:15,280 --> 00:10:17,240
kind of usage. 
Yeah, it's common parlance, 

226
00:10:17,280 --> 00:10:21,080
yeah, But the source material is
careful to point out that in its

227
00:10:21,080 --> 00:10:24,320
original strict definition, the 
one from Optic and Fowler that 

228
00:10:24,320 --> 00:10:28,160
we've been discussing, 
refactoring only refers to 

229
00:10:28,160 --> 00:10:31,160
changes that improve the 
maintainability of the source 

230
00:10:31,160 --> 00:10:34,840
code while preserving behavior. 
So improving performance isn't 

231
00:10:34,840 --> 00:10:37,720
technically refactoring by that 
strict definition. 

232
00:10:37,960 --> 00:10:40,440
Correct. 
Improving performance often 

233
00:10:40,440 --> 00:10:43,960
involves changing algorithms or 
data structures in ways that do 

234
00:10:43,960 --> 00:10:46,960
affect behavior, at least in 
terms of speed or resource 

235
00:10:46,960 --> 00:10:49,160
usage. 
Or it might even require 

236
00:10:49,160 --> 00:10:52,040
functional changes. 
That's performance optimization,

237
00:10:52,200 --> 00:10:55,600
a different valuable activity, 
but not refactoring in the pure 

238
00:10:55,600 --> 00:10:58,080
sense. 
Same for adding concurrency or 

239
00:10:58,080 --> 00:11:01,080
changing usability. 
Those usually involve behavioral

240
00:11:01,080 --> 00:11:03,240
changes. 
So why is that distinction 

241
00:11:03,240 --> 00:11:04,920
important? 
Does it matter what we call it? 

242
00:11:05,160 --> 00:11:08,160
Well, using the term precisely 
helps avoid confusion. 

243
00:11:08,440 --> 00:11:10,760
If someone says they're 
refactoring, the team should 

244
00:11:10,760 --> 00:11:13,080
understand that means improving 
internal structure without 

245
00:11:13,080 --> 00:11:16,760
changing external behavior. 
If they actually mean rewrite 

246
00:11:16,760 --> 00:11:19,320
this part for speed, that has 
different implications for 

247
00:11:19,320 --> 00:11:22,080
testing scope and risk. 
So clarity matters for 

248
00:11:22,080 --> 00:11:25,520
communication and expectations. 
OK, that's a really useful 

249
00:11:25,520 --> 00:11:28,400
clarification. 
It nails down what we mean when 

250
00:11:28,400 --> 00:11:30,280
we talk about refactoring in its
core sense. 

251
00:11:30,760 --> 00:11:33,880
So wrapping this part up, what 
this means for you, the 

252
00:11:33,880 --> 00:11:36,280
listener, is that when we talk 
refactoring based on this 

253
00:11:36,280 --> 00:11:41,040
material, we mean those specific
internal code improvements. 

254
00:11:41,560 --> 00:11:45,280
The goal is purely making the 
code healthier, easier to work 

255
00:11:45,280 --> 00:11:48,240
on in the future, all while 
guaranteeing it still does 

256
00:11:48,240 --> 00:11:51,160
exactly what it did before. 
It's that essential code 

257
00:11:51,160 --> 00:11:52,600
hygiene. 
Couldn't have said it better 

258
00:11:52,600 --> 00:11:54,240
myself. 
Yeah, it's about long term 

259
00:11:54,240 --> 00:11:57,000
sustainability. 
And that wraps up our depth dive

260
00:11:57,000 --> 00:12:00,320
into the world of refactoring, a
really crucial practice for any 

261
00:12:00,400 --> 00:12:02,640
healthy, long lasting software 
system. 

262
00:12:02,640 --> 00:12:05,040
Absolutely essential stuff. 
Thank you for joining us.