1
00:00:03,921 --> 00:00:04,641
All right.

2
00:00:05,081 --> 00:00:10,341
So today I figured I'd pick a nice uncontroversial topic that nobody has any opinions about.

3
00:00:10,961 --> 00:00:11,441
Right?

4
00:00:11,761 --> 00:00:14,981
Nobody has said anything on this about social media.

5
00:00:15,781 --> 00:00:20,421
And of course every take about this on social media is really deeply nuanced.

6
00:00:21,441 --> 00:00:24,801
People have lots of depth and really big thoughts.

7
00:00:24,801 --> 00:00:29,401
You know, maybe there's a little bit more to it than like yes or no.

8
00:00:30,001 --> 00:00:33,501
And, you know, of course, if you ever ask a senior engineer a question, we always have

9
00:00:33,501 --> 00:00:37,161
the same answer to every question, every senior engineer's favorite answer to every question,

10
00:00:37,341 --> 00:00:39,461
which is, it depends.

11
00:00:41,481 --> 00:00:47,101
Now, that's not a very helpful answer, though, frankly, because what does it depend on?

12
00:00:47,581 --> 00:00:49,621
So let's start with this.

13
00:00:50,061 --> 00:00:52,341
Why did code quality ever matter in the first place?

14
00:00:52,881 --> 00:00:55,001
I see a lot of people be like, well, it made me feel good.

15
00:00:55,461 --> 00:00:57,241
That's not really a sufficient justification.

16
00:00:57,981 --> 00:01:02,221
So let's see if we can inject some nuance into this conversation and help everybody at

17
00:01:02,221 --> 00:01:05,841
least be able to have a basis for reasoning about it while we're discussing it.

18
00:01:05,901 --> 00:01:07,221
So let's see if we can make a framework here.

19
00:01:07,301 --> 00:01:08,441
That's what we're going to try to do with this talk.

20
00:01:10,401 --> 00:01:14,061
So we're going to start off with everything you want to ever accomplish with a piece of

21
00:01:14,061 --> 00:01:17,701
software depends on two factors and two factors alone.

22
00:01:17,861 --> 00:01:20,941
And that is understanding and executing on that understanding.

23
00:01:20,941 --> 00:01:25,601
Whether that's aligning a model, scaling a system, driving adoption, anything, all software

24
00:01:25,601 --> 00:01:28,161
success is determined by these two factors.

25
00:01:28,461 --> 00:01:32,801
This is why we have things like debuggers and observability and evals and even tests.

26
00:01:33,161 --> 00:01:36,641
All those things actually are there to improve your understanding or ability to execute on

27
00:01:36,641 --> 00:01:37,101
that understanding.

28
00:01:37,241 --> 00:01:40,561
People think that they're there for other reasons, but fundamentally they're there for that reason.

29
00:01:41,381 --> 00:01:48,041
Everything we have ever done in the field of code quality is exclusively and only for

30
00:01:48,041 --> 00:01:48,861
these two things.

31
00:01:49,281 --> 00:01:50,421
It's not for anything else.

32
00:01:50,421 --> 00:01:52,801
And that doesn't have something to do with correctness or something else.

33
00:01:52,881 --> 00:01:54,301
It has to do only with these two things.

34
00:01:55,501 --> 00:01:58,201
Now, there's two understandings that are the most important to have

35
00:01:58,201 --> 00:01:59,561
if you're going to be a software engineer.

36
00:01:59,921 --> 00:02:02,181
There are other understandings to have about software,

37
00:02:02,181 --> 00:02:03,861
if you're going to be a product, if you're going to be in sales.

38
00:02:04,021 --> 00:02:06,541
But if you're a software engineer, there's the two that are the most important.

39
00:02:06,781 --> 00:02:10,121
And the first is, what is the behavior of the system?

40
00:02:10,261 --> 00:02:13,561
Like, concretely, not what does a doc say the behavior of the system is,

41
00:02:13,601 --> 00:02:15,361
but what is the actual behavior of the system?

42
00:02:15,361 --> 00:02:20,541
And the second one is, how do I correctly and safely modify that behavior?

43
00:02:22,781 --> 00:02:26,701
On a very small system, if you want to understand what the system does,

44
00:02:27,761 --> 00:02:29,261
I just tell you what it does.

45
00:02:29,441 --> 00:02:30,821
It prints hello world.

46
00:02:30,941 --> 00:02:32,341
You say, I wanted to say hi world.

47
00:02:32,441 --> 00:02:34,841
I say, okay, I will make it say hi world now.

48
00:02:35,041 --> 00:02:39,221
There's very little to understand about it other than purely what it does.

49
00:02:39,521 --> 00:02:41,301
That's all of the understanding that you need.

50
00:02:41,301 --> 00:02:45,461
However, any real software system is enormously complex.

51
00:02:45,841 --> 00:02:50,221
This is a real map of the code base of Chromium,

52
00:02:50,401 --> 00:02:53,261
which is the open source project behind Chrome.

53
00:02:53,741 --> 00:02:56,501
And if you think about all of the different ways

54
00:02:56,501 --> 00:02:57,781
that these components can interact,

55
00:02:58,101 --> 00:03:01,181
they have essentially infinite possible behaviors.

56
00:03:01,761 --> 00:03:04,961
Like, I could not describe to you in words

57
00:03:04,961 --> 00:03:08,781
the behavior of Chromium as a whole, as a system.

58
00:03:09,601 --> 00:03:14,221
However, what I can describe to you, and as we all know, everybody's been a software engineer

59
00:03:14,221 --> 00:03:17,801
for a while, I can describe to you components of the system.

60
00:03:17,961 --> 00:03:22,701
I can successfully describe to you how a component of the system behaves.

61
00:03:22,881 --> 00:03:27,521
So this is the URL parser, the actual functions and stuff for the URL parser of Chromium.

62
00:03:27,521 --> 00:03:29,801
It figures out all the different parts of the URL.

63
00:03:31,241 --> 00:03:36,301
And this is the whole reason that code exists.

64
00:03:36,301 --> 00:03:41,781
The whole reason that we have code at all in the first place is for structure.

65
00:03:43,701 --> 00:03:44,801
What do I mean by that?

66
00:03:47,181 --> 00:03:52,221
Both of these two things on the left and on the right will print Hello World if run on

67
00:03:52,221 --> 00:03:53,001
a Linux machine.

68
00:03:53,661 --> 00:03:58,041
However, on the left you can see that it is Hello World.

69
00:03:58,221 --> 00:04:01,761
It has the identity and structure of Hello World.

70
00:04:01,761 --> 00:04:07,161
On the right, you just see a series of instructions with no particular identity, recognizable

71
00:04:07,161 --> 00:04:08,301
or understandable identity.

72
00:04:08,521 --> 00:04:09,401
It's not a component.

73
00:04:09,621 --> 00:04:10,961
It's just a bunch of instructions.

74
00:04:11,321 --> 00:04:15,461
While that's understandable there, if that was millions or billions of lines of that,

75
00:04:15,581 --> 00:04:17,301
it would be much harder to grok.

76
00:04:17,681 --> 00:04:23,181
In the past, we've talked about things like readability or testability or things that

77
00:04:23,181 --> 00:04:25,021
seemed like human concepts about code.

78
00:04:25,321 --> 00:04:30,701
But what actually mattered the most always was that the system had some sort of understandable

79
00:04:30,701 --> 00:04:31,261
structure.

80
00:04:31,261 --> 00:04:33,121
So it's the structure that actually matters.

81
00:04:34,701 --> 00:04:41,961
And when this matters the most is when you want to modify the system, the second understanding

82
00:04:41,961 --> 00:04:42,721
that we talked about.

83
00:04:43,441 --> 00:04:46,661
All modifications to a system carry two categories of risk.

84
00:04:46,941 --> 00:04:49,501
The first is that you will introduce some sort of problem.

85
00:04:49,701 --> 00:04:53,201
And a problem isn't just a bug, it's anything bad that could happen.

86
00:04:53,441 --> 00:04:55,881
Like your project could take much longer than you expect.

87
00:04:56,281 --> 00:04:59,341
It could not behave in the way that you wanted it to for your users.

88
00:04:59,341 --> 00:05:02,121
The project could fail because you have budget overruns.

89
00:05:02,201 --> 00:05:07,061
Any kind of problem could happen from just you trying to go through the process of making this change.

90
00:05:07,261 --> 00:05:11,101
And the second is you could make it harder to make future changes.

91
00:05:11,341 --> 00:05:14,781
In particular, what that means is you could make it more likely to have future problems.

92
00:05:14,861 --> 00:05:16,781
You could increase future risk of the system.

93
00:05:17,701 --> 00:05:23,641
These two things are caused by problems with understanding.

94
00:05:23,821 --> 00:05:28,321
So the first has to do with the difficulty of understanding the system in the first place.

95
00:05:28,321 --> 00:05:32,241
And the second is you make the system harder to understand.

96
00:05:33,201 --> 00:05:38,521
can reduce every post-mortem I have ever read for any incident to these two factors

97
00:05:38,521 --> 00:05:40,001
in one way or another.

98
00:05:40,661 --> 00:05:43,021
The production configuration was too hard to understand.

99
00:05:43,141 --> 00:05:44,421
Somebody made something impossible to understand.

100
00:05:44,781 --> 00:05:47,241
There were emergent properties of the system that were impossible to understand.

101
00:05:47,461 --> 00:05:47,541
Whatever.

102
00:05:48,901 --> 00:05:58,081
Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion.

103
00:05:58,321 --> 00:06:03,001
So the difficulty of understanding does not grow linearly, it compounds over time.

104
00:06:03,981 --> 00:06:08,081
You will eventually reach a point, and all systems eventually tend to reach this point,

105
00:06:08,381 --> 00:06:12,181
where every modification involves some sort of problem.

106
00:06:15,661 --> 00:06:22,141
Some systems get to the point where you can't modify them at, if you think of your giant

107
00:06:22,141 --> 00:06:27,361
100 million, 500 million line mainframe code bases, everything, every change is some sort

108
00:06:27,361 --> 00:06:27,721
of problem.

109
00:06:28,041 --> 00:06:31,421
You'll see it in organizational issues, you'll see it all over the place, you'll see it in

110
00:06:31,421 --> 00:06:32,301
timelines, whatever.

111
00:06:33,401 --> 00:06:37,061
And look, there's a lot of arguments about maybe future models will fix this.

112
00:06:37,161 --> 00:06:40,601
Look, maybe they will, maybe future models will have infinite ability to deal with complexity

113
00:06:40,601 --> 00:06:41,001
somehow.

114
00:06:42,061 --> 00:06:47,181
But we don't have to discuss that today because I think models are doing something else really

115
00:06:47,181 --> 00:06:48,021
interesting right now.

116
00:06:48,601 --> 00:06:53,781
They are creating a new kind of software, a new category of software.

117
00:06:53,781 --> 00:07:01,281
This category has always existed, but it's about to become 100,000 times more common

118
00:07:01,281 --> 00:07:06,901
than any other form of software, and that is disposable software.

119
00:07:07,641 --> 00:07:08,641
So what is that?

120
00:07:09,981 --> 00:07:16,241
Okay, so imagine a world in which the consequences of failure for your system are very minimal

121
00:07:16,241 --> 00:07:16,901
or nonexistent.

122
00:07:17,341 --> 00:07:22,241
Imagine that there's very few people that depend on it, and almost no other systems depend

123
00:07:22,241 --> 00:07:23,141
on that piece of software.

124
00:07:23,781 --> 00:07:26,841
Change management, very minimal, non-existent.

125
00:07:27,221 --> 00:07:30,741
Imagine the cost of replacement went to near zero.

126
00:07:31,061 --> 00:07:33,701
You could replace the whole thing in hours or days.

127
00:07:33,941 --> 00:07:36,161
And it had basically no cost of maintenance.

128
00:07:36,941 --> 00:07:42,961
In that world, code quality does not matter.

129
00:07:43,561 --> 00:07:46,321
Because all of those things we were trying to prevent

130
00:07:46,321 --> 00:07:50,101
about the compounding risks over time don't exist.

131
00:07:52,561 --> 00:07:55,921
Traditionally, we've always built durable software.

132
00:07:57,161 --> 00:08:01,721
lives for years, it's depended on millions or thousands of people, there's huge consequences

133
00:08:01,721 --> 00:08:06,841
of failure, potentially business catastrophic consequences of failure, and it requires enormous

134
00:08:06,841 --> 00:08:07,261
maintenance.

135
00:08:07,521 --> 00:08:11,341
Most of the software engineers in the world spend most of their time maintaining these

136
00:08:11,341 --> 00:08:12,521
giant durable systems.

137
00:08:13,601 --> 00:08:16,801
I expect this to continue to exist.

138
00:08:16,801 --> 00:08:20,621
So this is one of the areas where I think sometimes the conversation goes a little astray.

139
00:08:22,001 --> 00:08:28,961
Durable systems will continue to probably be the most important systems in the world.

140
00:08:29,201 --> 00:08:31,361
And there will be probably more of them.

141
00:08:31,621 --> 00:08:37,721
But the most numerous systems will be disposable software.

142
00:08:37,981 --> 00:08:39,681
They will be replaceable in hours.

143
00:08:39,681 --> 00:08:41,061
They will be depended on by a few.

144
00:08:41,201 --> 00:08:42,721
Or change management just won't matter.

145
00:08:43,221 --> 00:08:46,341
And look, if it doesn't work, we'll give everybody agents.

146
00:08:46,341 --> 00:08:47,841
They'll make a version of it themselves.

147
00:08:49,421 --> 00:08:51,161
Maintenance will be unimportant or nearly free.

148
00:08:51,421 --> 00:08:53,181
Don't like the calculator on your OS?

149
00:08:53,381 --> 00:08:54,121
Make your own.

150
00:08:54,701 --> 00:08:56,481
Want to plan a party for your kids?

151
00:08:56,701 --> 00:09:00,301
Write a party planner software just for that one party.

152
00:09:01,121 --> 00:09:01,941
Throw it away.

153
00:09:02,041 --> 00:09:02,701
Code quality doesn't matter.

154
00:09:02,761 --> 00:09:03,161
Nobody cares.

155
00:09:04,581 --> 00:09:11,741
In the future, we will apply engineering rigor to the degree of disposability of the software.

156
00:09:11,741 --> 00:09:16,901
On the left, nothing, none of our practices of engineering rigor matter at all.

157
00:09:17,741 --> 00:09:22,741
On the right, all the practices of engineering that we have built up over the last many decades

158
00:09:22,741 --> 00:09:23,821
matter greatly.

159
00:09:24,181 --> 00:09:29,221
We can determine where you are on this scale by those four factors that I have been talking

160
00:09:29,221 --> 00:09:29,641
about.

161
00:09:30,121 --> 00:09:33,241
Consequences, cost of replacement, dependencies, and cost of maintenance.

162
00:09:33,581 --> 00:09:34,941
If they're all low, it's

163
00:09:35,021 --> 00:09:37,941
disposable software. If they're all high, it's durable software.

164
00:09:38,361 --> 00:09:46,441
And look, any person who's written software for a long time knows you should err on the side of it being durable. You should err on these all being higher than you expect them to be.

165
00:09:47,921 --> 00:09:57,481
But there's also a new thing you can do in the world. You can make software more disposable. So, like, what does that involve?

166
00:09:57,481 --> 00:10:01,681
Well, come up with better isolated environments.

167
00:10:01,941 --> 00:10:05,361
So, hey, you can only deploy to this environment that has access to only your data.

168
00:10:05,501 --> 00:10:08,901
No customer data, no personally identifiable information, whatever.

169
00:10:09,721 --> 00:10:12,001
You can enforce independence.

170
00:10:12,181 --> 00:10:17,321
You can say, okay, no inbound API calls from other production systems are allowed to this

171
00:10:17,321 --> 00:10:18,501
system in this environment.

172
00:10:18,781 --> 00:10:21,461
And so everything deployed to that environment is disposable.

173
00:10:22,421 --> 00:10:22,941
Redundancy.

174
00:10:22,941 --> 00:10:27,381
You can have an old clunky backup system that is hard to use.

175
00:10:27,781 --> 00:10:30,541
And then, look, if people want to vibe code their own more efficient front ends,

176
00:10:30,641 --> 00:10:32,561
you let them vibe code their own more efficient front ends

177
00:10:32,561 --> 00:10:36,481
because there is an old, durable, clunky backup system that they can use

178
00:10:36,481 --> 00:10:38,841
if their crappy little vibe-coded thing fails.

179
00:10:39,661 --> 00:10:42,301
Which it will fail. That's fine. But it doesn't matter if it fails.

180
00:10:43,501 --> 00:10:45,461
And you can limit scope, just like I talked about.

181
00:10:45,721 --> 00:10:47,801
It's just a calculator for this one person.

182
00:10:48,061 --> 00:10:49,941
It just plans this one party.

183
00:10:49,941 --> 00:10:56,321
There's so much more we could do here and talk about ways of increasing disposability.

184
00:10:56,641 --> 00:11:01,541
In fact, I think this is a whole new discipline of software engineering.

185
00:11:01,741 --> 00:11:07,121
Not to think about how we improve the rigor of durable systems, but how do we take our

186
00:11:07,121 --> 00:11:12,021
systems and how do we encourage disposability or allow more disposability, allow people

187
00:11:12,021 --> 00:11:13,021
to throw these things away.

188
00:11:13,821 --> 00:11:14,601
Interesting thought.

189
00:11:14,601 --> 00:11:21,861
Now, I want to re-emphasize that durable software engineering is not going away because this

190
00:11:21,861 --> 00:11:24,961
is the biggest confusion that I see on social media today.

191
00:11:25,301 --> 00:11:29,901
In fact, I believe the absolute amount of durable software in the world will increase

192
00:11:29,901 --> 00:11:35,861
because AI coding tools make it easier and easier to make more durable software.

193
00:11:36,941 --> 00:11:41,981
another important thing to understand is that disposable and durable are not black

194
00:11:41,981 --> 00:11:42,341
and white.

195
00:11:42,341 --> 00:11:46,941
There's a spectrum, like I showed before, but that spectrum, what changes across the

196
00:11:46,941 --> 00:11:50,941
spectrum is how much effort you're going to put into engineering rigor.

197
00:11:51,281 --> 00:11:51,781
Okay?

198
00:11:52,041 --> 00:11:55,921
And that's both immediate effort and effort over time, just like we've always talked about

199
00:11:55,921 --> 00:11:56,681
for software.

200
00:11:57,701 --> 00:12:02,901
However, what you want to do, and I think what you want to care about the most, is reducing

201
00:12:02,901 --> 00:12:04,961
the cost of effort.

202
00:12:05,281 --> 00:12:06,661
Reducing the cost of rigor.

203
00:12:08,121 --> 00:12:13,861
like if rigor is cheaper if it's the easier and easier you make it to be rigor the less you have

204
00:12:13,861 --> 00:12:18,181
to worry about where you are on the scale so this is another approach you can take

205
00:12:19,121 --> 00:12:23,801
if you change your mind it's much easier to like you're like oh i thought this was going to be

206
00:12:23,801 --> 00:12:28,981
disposable and now it needs to be durable the cheaper you make it to make it durable the easier

207
00:12:28,981 --> 00:12:33,601
it is to change your mind or to be wrong because you're never going to be 100 right all the time

208
00:12:33,601 --> 00:12:39,161
on that estimate. So that involves a different set of practices that are not engineering

209
00:12:39,161 --> 00:12:44,801
rigor themselves, but that are about how to decrease the cost of engineering rigor.

210
00:12:45,361 --> 00:12:49,401
Now, I could talk about this for hours. I have spent a tremendous amount of my career

211
00:12:49,401 --> 00:12:54,341
doing this. I don't have 10 hours. I have about five minutes left on that timer. So

212
00:12:54,341 --> 00:13:01,441
I'll talk about what I can, okay? Let's talk about standardization. Why do we do standardization?

213
00:13:01,441 --> 00:13:03,721
People are like, well, I don't know, because the boss said so.

214
00:13:03,821 --> 00:13:05,061
Well, no.

215
00:13:05,441 --> 00:13:08,841
We do standardization because it removes possibilities.

216
00:13:09,961 --> 00:13:12,641
If you don't have any PHP in your system,

217
00:13:12,841 --> 00:13:15,741
you don't have to figure out what are all the linters for PHP,

218
00:13:15,881 --> 00:13:18,461
what are all the practices, what are all the security holes I have to fix.

219
00:13:18,641 --> 00:13:21,321
You just eliminate possibilities through standardization,

220
00:13:21,481 --> 00:13:24,241
and it just reduces the cost of rigor.

221
00:13:25,201 --> 00:13:26,321
Same thing with frameworks.

222
00:13:26,561 --> 00:13:28,641
Why don't you want to have every front-end framework

223
00:13:28,641 --> 00:13:30,481
or every back-end framework in existence?

224
00:13:30,861 --> 00:13:32,681
because it makes rigor more expensive.

225
00:13:33,061 --> 00:13:34,141
Like, yes, rigor is still possible.

226
00:13:34,261 --> 00:13:36,161
Yes, you could still have the agent code up all your tools,

227
00:13:36,281 --> 00:13:37,701
but you have to do it every single time.

228
00:13:38,781 --> 00:13:40,101
You know, protocols,

229
00:13:40,501 --> 00:13:42,081
why do you want to have standardized RPC protocols?

230
00:13:42,221 --> 00:13:42,761
All the same thing.

231
00:13:43,521 --> 00:13:44,741
Standards are all for this reason.

232
00:13:45,361 --> 00:13:45,681
Okay?

233
00:13:46,561 --> 00:13:47,981
What I call in-workflow tooling.

234
00:13:48,081 --> 00:13:49,881
So in-workflow tooling is tooling that just occurs.

235
00:13:50,141 --> 00:13:51,741
The programmer doesn't have to choose to run it.

236
00:13:51,801 --> 00:13:53,261
They don't have to understand how it runs.

237
00:13:53,421 --> 00:13:54,341
It just happens.

238
00:13:54,601 --> 00:13:57,701
If it's there, it feels and seems free,

239
00:13:57,721 --> 00:13:59,281
and it is reliable.

240
00:13:59,781 --> 00:14:01,101
Reliability is very, very important.

241
00:14:01,401 --> 00:14:03,021
It doesn't have a ton of false positives.

242
00:14:03,261 --> 00:14:05,081
It's fast. It just happens.

243
00:14:05,501 --> 00:14:08,681
And the more that's true, you can apply it to your disposable software too.

244
00:14:08,801 --> 00:14:10,081
If it's free and fast, who cares?

245
00:14:12,421 --> 00:14:13,601
Making testing easier.

246
00:14:13,761 --> 00:14:16,281
So this is not just about, like, hey, how do we do better testing?

247
00:14:17,081 --> 00:14:20,581
Look, how do you make it so that nobody has to think about how to do better testing?

248
00:14:21,241 --> 00:14:25,321
How do you make it so that every test is fast and deterministic

249
00:14:25,321 --> 00:14:28,121
without anybody having to be a deep expert in testing?

250
00:14:28,121 --> 00:14:33,581
There's a ton of work that you have to put into test infrastructure to make that possible.

251
00:14:33,961 --> 00:14:38,821
For example, one of the great dreams that I've always had as a test owner is that everybody

252
00:14:38,821 --> 00:14:42,721
would provide in-memory fake versions of their services and I could just run those in-memory

253
00:14:42,721 --> 00:14:43,821
fake versions of their services.

254
00:14:44,061 --> 00:14:44,521
Guess what?

255
00:14:44,861 --> 00:14:46,121
The coding agent can do that.

256
00:14:46,221 --> 00:14:47,401
So you can just do that now.

257
00:14:47,781 --> 00:14:50,621
But you have to choose to do it and make it available to everybody.

258
00:14:51,601 --> 00:14:54,521
And another thing is, look, maximum strictness.

259
00:14:54,681 --> 00:14:56,081
You just turn the strictness up everywhere.

260
00:14:56,081 --> 00:14:58,261
You set all your lint rules to maximum.

261
00:14:58,701 --> 00:15:00,421
You never compromise on anything.

262
00:15:01,001 --> 00:15:03,641
And it eliminates, it's very similar to standardization.

263
00:15:03,921 --> 00:15:05,101
It eliminates a ton of conversations.

264
00:15:05,521 --> 00:15:06,501
Sometimes the linter is wrong.

265
00:15:06,601 --> 00:15:09,901
As long as the false positive rate is relatively low and doesn't have catastrophic consequences,

266
00:15:10,101 --> 00:15:14,621
it doesn't matter because all of a sudden there's a bunch of future lint errors or future

267
00:15:14,621 --> 00:15:15,681
issues that you don't have to deal with.

268
00:15:15,981 --> 00:15:20,061
Ask anybody who's been like, oh, I suddenly want to turn on my linter in this million

269
00:15:20,061 --> 00:15:20,781
line code base.

270
00:15:20,881 --> 00:15:21,741
And they're like, oh, wow.

271
00:15:22,101 --> 00:15:25,101
Now here's my 100,000 line change that I need to make.

272
00:15:25,101 --> 00:15:27,661
Much easier to do that up front and have it on for everybody.

273
00:15:28,081 --> 00:15:32,541
Now look, like I said, I could literally stand here and talk to you about this straight for

274
00:15:32,541 --> 00:15:32,981
ten hours.

275
00:15:33,181 --> 00:15:35,441
There is much, much more you can do here.

276
00:15:35,581 --> 00:15:39,961
This is just a few areas, but also a whole area of software engineering discipline that

277
00:15:39,961 --> 00:15:41,261
you can apply on the other axis.

278
00:15:42,321 --> 00:15:48,301
So this lets us now answer our question, not just it depends, but yes or no.

279
00:15:48,761 --> 00:15:51,481
So does code quality even matter?

280
00:15:51,481 --> 00:15:54,681
For disposable software, no.

281
00:15:55,721 --> 00:15:58,461
For durable software, yes.

282
00:15:58,781 --> 00:16:01,721
And we get to answer a third and even more interesting question,

283
00:16:01,901 --> 00:16:04,141
which is, does it have to be expensive?

284
00:16:04,961 --> 00:16:05,621
No.

285
00:16:06,201 --> 00:16:07,341
Thank you very much.