WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=bU5gDVyu_28

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/bU5gDVyu_28.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.680 --> 00:00:18.680
So, today I figured I'd just pick a nice uncontroversial topic that nobody has any opinions about.

s3
00:00:18.680 --> 00:00:19.200
Right?

s4
00:00:19.200 --> 00:00:32.720
Nobody nobody said anything on about on this about social media, you know, and of course every take about this on social media is like really deeply nuanced, you know, like people have lots of like depth and like, you know, really big thoughts.

s5
00:00:32.720 --> 00:00:45.040
You know, maybe there's a little bit more to it than like yes or no. And you know, of course if you ever ask a senior engineer a question, we always have the same answer to every question, every senior engineer's favorite answer to every question,

s6
00:00:45.040 --> 00:00:48.320
which is it depends.

s7
00:00:48.560 --> 00:00:55.080
Now, that's not a very helpful answer though, frankly, because what does it depend on?

s8
00:00:55.080 --> 00:00:57.680
So, let's start with this.

s9
00:00:57.680 --> 00:01:00.200
Why did code quality ever matter in the first place?

s10
00:01:00.200 --> 00:01:02.840
Like I see a lot of people be like, well, it made me feel good.

s11
00:01:02.840 --> 00:01:05.320
That's not really a sufficient justification.

s12
00:01:05.320 --> 00:01:13.240
So, let's see if we can inject some nuance into this conversation and help everybody at least be able to have a basis for reasoning about it while we're discussing it.

s13
00:01:13.240 --> 00:01:17.120
So, let's see if we can make a framework here and that's what we're going to try to do with this talk.

s14
00:01:17.120 --> 00:01:18.000
Okay.

s15
00:01:18.000 --> 00:01:25.480
So, we're going to start off with everything you want to ever accomplish with a piece of software uh depends on two factors and two factors alone.

s16
00:01:25.480 --> 00:01:32.320
And that is understanding and executing on that understanding, whether that's aligning a model, scaling a system, driving adoption, anything.

s17
00:01:32.320 --> 00:01:36.040
All software success is determined by these two factors.

s18
00:01:36.040 --> 00:01:40.600
This is why we have things like debuggers and observability and evals and even tests.

s19
00:01:40.600 --> 00:01:44.600
All those things actually are there to improve your understanding or ability to execute on that understanding.

s20
00:01:44.600 --> 00:01:48.880
People think that they're there for other reasons, but fundamentally they're there for that reason.

s21
00:01:48.880 --> 00:01:56.840
Everything we have ever done in the field of code quality is exclusively and only for these two things.

s22
00:01:56.840 --> 00:01:57.880
It's not for anything else.

s23
00:01:57.880 --> 00:02:00.200
Not doesn't have something to do with correctness or something else.

s24
00:02:00.200 --> 00:02:02.520
It has to do only with these two things.

s25
00:02:02.520 --> 00:02:07.479
Now, there's two understandings that are the most important to have if you're going to be a software engineer.

s26
00:02:07.479 --> 00:02:14.320
There are other understandings to have about software if you're going to be a product, if you're going to be in sales, but if you're a software engineer, there's the two that are the most important.

s27
00:02:14.320 --> 00:02:17.600
And the first is what is the behavior of the system?

s28
00:02:17.600 --> 00:02:23.320
Like con- the concretely, not what does a doc say the behavior of the system is, but what is the actual behavior of the system?

s29
00:02:23.320 --> 00:02:30.280
And the second one is how do I correctly and safely modify that behavior, okay?

s30
00:02:30.480 --> 00:02:36.959
On a very small system, if you want to understand what the system does, I just tell you what it does.

s31
00:02:36.959 --> 00:02:38.280
It prints hello world.

s32
00:02:38.280 --> 00:02:39.800
You say, "I want it to say hi world."

s33
00:02:39.800 --> 00:02:42.520
I say, "Okay, I will make it say hi world now."

s34
00:02:42.520 --> 00:02:46.840
There's very little to understand about it other than purely what it does.

s35
00:02:46.840 --> 00:02:49.040
That's all of the understanding that you need.

s36
00:02:49.040 --> 00:02:53.400
However, any real software system is enormously complex.

s37
00:02:53.400 --> 00:03:01.480
This is a real map of the code base of Chromium, which is the open-source project behind Chrome.

s38
00:03:01.480 --> 00:03:09.560
And if you think about all of the different ways that these components can interact, they have essentially infinite possible behaviors.

s39
00:03:09.560 --> 00:03:17.120
Like, I could not describe to you in words the behavior of Chromium as a whole as a system.

s40
00:03:17.120 --> 00:03:25.320
However, what I can describe to you, and as we all know, everybody's been a software engineer for a while, I can describe to you components of the system.

s41
00:03:25.320 --> 00:03:30.160
I can successfully describe to you how a component of the system behaves.

s42
00:03:30.160 --> 00:03:35.000
So, this is the URL parser, the actual functions and stuff for the URL parser of Chromium.

s43
00:03:35.000 --> 00:03:37.959
It figures out all the different parts of the URL.

s44
00:03:37.959 --> 00:03:44.400
And this is the whole reason that code exists.

s45
00:03:44.400 --> 00:03:50.440
The whole reason that we have code at all in the first place is for structure.

s46
00:03:50.760 --> 00:03:53.080
It Because it What do I mean by that?

s47
00:03:53.080 --> 00:03:54.360
Okay.

s48
00:03:54.360 --> 00:04:01.240
So, both of these two things on the left and on the right will print Hello World if run on a Linux machine.

s49
00:04:01.240 --> 00:04:05.520
However, on the left, you can see that it is Hello World.

s50
00:04:05.520 --> 00:04:09.520
It has the identity and structure of Hello World.

s51
00:04:09.520 --> 00:04:16.000
On the right, you just see a series of instructions with no particular identity, recognizable or understandable identity.

s52
00:04:16.000 --> 00:04:18.720
It's not a component, it's just a bunch of instructions.

s53
00:04:18.720 --> 00:04:25.480
While that's understandable there, if that was millions or billions of lines of that, it would be much harder to grok.

s54
00:04:25.480 --> 00:04:38.720
In the past, we've talked about things like readability or testability or things that seemed like human concepts about code, but what actually mattered the most always was that the system had some sort of understandable structure.

s55
00:04:38.720 --> 00:04:42.200
So, it's the structure that actually matters.

s56
00:04:42.200 --> 00:04:51.000
And when this modifies when this matters the most is when you want to modify the system, the second uh understanding that we talked about.

s57
00:04:51.000 --> 00:04:54.600
All modifications to a system carry two categories of risk.

s58
00:04:54.600 --> 00:04:57.200
The first is that you will introduce some sort of problem.

s59
00:04:57.200 --> 00:05:00.880
And a problem isn't just a bug, it's anything bad that could happen.

s60
00:05:00.880 --> 00:05:03.880
Like your project could take much longer than you expect.

s61
00:05:03.880 --> 00:05:06.960
Uh it could not behave in the way that you wanted it to for your users.

s62
00:05:06.960 --> 00:05:09.800
The project could fail because you have budget overruns.

s63
00:05:09.800 --> 00:05:14.880
Any kind of problem could happen from just you trying to go through the process of making this change.

s64
00:05:14.880 --> 00:05:19.040
And the second is you could make it harder to make future changes.

s65
00:05:19.040 --> 00:05:22.240
In particular, what that means is you can make it more likely to have future problems.

s66
00:05:22.240 --> 00:05:25.320
You could increase future risk of the system.

s67
00:05:25.320 --> 00:05:31.120
These two things are caused by under problems with understanding.

s68
00:05:31.120 --> 00:05:40.440
So, the first has to do with the difficulty of understanding the system in the first place, and the second is you make the system harder to understand.

s69
00:05:40.440 --> 00:05:56.680
I can reduce every postmortem I have ever read for any incident to these two factors in one way or The the production configuration was too hard to understand, somebody made something impossible to understand, there were emergent properties of the system that were impossible to understand, whatever.

s70
00:05:56.680 --> 00:06:05.960
Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion.

s71
00:06:05.960 --> 00:06:11.720
So, the difficulty of understanding does not grow linearly, it compounds over time.

s72
00:06:11.720 --> 00:06:21.120
You will eventually reach a point, and all systems eventually tend to reach this point, where every modification involves some sort of problem.

s73
00:06:21.960 --> 00:06:33.200
Uh and you know, some some systems get to the point where like you can't modify them at like if you think of like, you know, some of like your giant 100 million 500 million line mainframe code bases and that

s74
00:06:33.200 --> 00:06:35.520
everything, every change is some sort of problem.

s75
00:06:35.520 --> 00:06:41.120
You know, you'll see it in organizational issues, you'll see it all over the place, you'll see it in timelines, whatever.

s76
00:06:41.120 --> 00:06:44.480
And look, there's a lot of arguments about maybe future models will fix this.

s77
00:06:44.480 --> 00:06:45.240
Look, maybe they will.

s78
00:06:45.240 --> 00:06:49.120
Maybe future models will have infinite ability to deal with complexity somehow.

s79
00:06:49.120 --> 00:06:56.240
Uh but we don't have to discuss that today because I think models are doing something else really interesting right now.

s80
00:06:56.240 --> 00:07:01.680
They are creating a new kind of software, a new category of software.

s81
00:07:01.680 --> 00:07:11.120
This category has always existed, but it's about to become a hundred thousand times more common than any other form of software.

s82
00:07:11.120 --> 00:07:15.520
And that is disposable software.

s83
00:07:15.520 --> 00:07:17.560
So, what is that?

s84
00:07:17.560 --> 00:07:18.160
Okay.

s85
00:07:18.160 --> 00:07:24.960
So, imagine a world in which the consequences of failure for your system are very minimal or non-existent.

s86
00:07:24.960 --> 00:07:31.480
Imagine that there's very few people that depend on it or and almost no other systems depend on that piece of software.

s87
00:07:31.480 --> 00:07:34.960
Change management, very minimal, non-existent.

s88
00:07:34.960 --> 00:07:38.640
Imagine the cost of replacement went to near zero.

s89
00:07:38.640 --> 00:07:41.720
You could replace the whole thing in hours or days.

s90
00:07:41.720 --> 00:07:44.760
And it had basically no cost of maintenance.

s91
00:07:44.760 --> 00:07:51.440
In that world, code quality does not matter.

s92
00:07:51.440 --> 00:07:59.040
Because it all of those things we were trying to prevent about the compounding risks over time don't exist.

s93
00:08:00.000 --> 00:08:04.200
Traditionally, we've always built durable software.

s94
00:08:04.200 --> 00:08:05.360
You know, it lives for years.

s95
00:08:05.360 --> 00:08:07.800
It's depended on by millions or thousands of people.

s96
00:08:07.800 --> 00:08:12.760
There's huge consequences of failure, potentially business catastrophic consequences of failure.

s97
00:08:12.760 --> 00:08:14.800
And it requires enormous maintenance.

s98
00:08:14.800 --> 00:08:21.480
Most of the software engineers in the world spend most of their time maintaining these giant durable systems.

s99
00:08:21.480 --> 00:08:24.320
I expect this to continue to exist.

s100
00:08:24.320 --> 00:08:29.480
So, this is one of the areas where I think sometimes the conversation goes a little astray, okay?

s101
00:08:29.480 --> 00:08:36.960
Durable systems will continue to probably be the most important systems in the world.

s102
00:08:36.960 --> 00:08:39.159
And there will be probably more of them.

s103
00:08:39.159 --> 00:08:45.640
But the most numerous systems will be disposable software.

s104
00:08:45.640 --> 00:08:47.280
They will be replaceable in hours.

s105
00:08:47.280 --> 00:08:50.880
They will be depended on by a few or change management just won't matter.

s106
00:08:50.880 --> 00:08:53.880
And look, if it doesn't work, you will give everybody agents.

s107
00:08:53.880 --> 00:08:56.440
They'll make a version of it themselves.

s108
00:08:56.440 --> 00:08:58.760
You know, maintenance will be unimportant or nearly free.

s109
00:08:58.760 --> 00:09:00.880
Don't like the calculator on your OS?

s110
00:09:00.880 --> 00:09:02.040
Make your own.

s111
00:09:02.040 --> 00:09:04.320
Want to plan a party for your kids?

s112
00:09:04.320 --> 00:09:08.880
Write a party planner software just for that one party.

s113
00:09:08.880 --> 00:09:09.360
Throw it away.

s114
00:09:09.360 --> 00:09:10.160
Code quality doesn't matter.

s115
00:09:10.160 --> 00:09:12.320
Nobody cares.

s116
00:09:12.320 --> 00:09:19.839
In the future, we will apply engineering rigor to the degree of disposability of the software.

s117
00:09:19.839 --> 00:09:21.839
On the left, nothing.

s118
00:09:21.839 --> 00:09:25.480
None of our practices of engineering rigor matter at all.

s119
00:09:25.480 --> 00:09:31.920
On the right, all the practices of engineering that we have built up over the last many decades matter greatly.

s120
00:09:31.920 --> 00:09:37.360
We can determine where you are on this scale by those four factors that I have been talking about.

s121
00:09:37.360 --> 00:09:41.160
Consequences, cost of replacement, dependencies, and cost of maintenance.

s122
00:09:41.160 --> 00:09:43.360
If they're all low, it's disposable software.

s123
00:09:43.360 --> 00:09:45.680
If they're all high, it's durable software.

s124
00:09:45.680 --> 00:09:51.000
And look, any person who's written software for a long time knows you should err on the side of it being durable.

s125
00:09:51.000 --> 00:09:54.920
You should err on these all being higher than you expect them to be.

s126
00:09:54.920 --> 00:10:00.000
But, there's also a new thing you can do in the world.

s127
00:10:00.000 --> 00:10:03.520
You can make software more disposable.

s128
00:10:03.520 --> 00:10:05.160
So, like, what do What does that involve?

s129
00:10:05.160 --> 00:10:09.440
Well, come up with better isolated environments, right?

s130
00:10:09.440 --> 00:10:13.080
So, hey, you can only deploy to this environment that has access to only your data.

s131
00:10:13.080 --> 00:10:17.480
No customer data, no personally identifiable information, whatever.

s132
00:10:17.480 --> 00:10:19.960
You can enforce independence.

s133
00:10:19.960 --> 00:10:26.560
You can say, "Okay, no inbound API calls from other production systems are allowed to this system in this environment, right?"

s134
00:10:26.560 --> 00:10:29.680
And so, everything deployed to that environment is disposable.

s135
00:10:29.680 --> 00:10:30.720
Redundancy.

s136
00:10:30.720 --> 00:10:35.080
You can have an old clunky backup system that is like hard to use.

s137
00:10:35.080 --> 00:10:47.280
And then, like, look, if people want to vibe code their own like more efficient front ends, you let them vibe code their more own more efficient front ends because there is an old durable clunky backup system that they can use if their, you know, crappy little vibe coded thing fails.

s138
00:10:47.280 --> 00:10:48.360
Which Which it will fail, right?

s139
00:10:48.360 --> 00:10:48.720
That's fine.

s140
00:10:48.720 --> 00:10:50.920
But, it doesn't matter if it fails.

s141
00:10:50.920 --> 00:10:53.280
Uh and you can limit scope, just like I talked about, right?

s142
00:10:53.280 --> 00:10:55.760
It's just a calculator for this one person.

s143
00:10:55.760 --> 00:10:58.080
It just plans this one party.

s144
00:10:58.080 --> 00:11:04.160
There's so much more we could do here and talk about ways of increasing disposability.

s145
00:11:04.160 --> 00:11:17.320
In fact, I think this is a whole new discipline of software engineering, not to think about how we improve the rigor of durable systems, but how do we take our systems and how do we encourage disposability

s146
00:11:17.320 --> 00:11:21.440
or allow more disposability, allow people to throw these things away.

s147
00:11:21.440 --> 00:11:22.920
Interesting thought.

s148
00:11:22.920 --> 00:11:32.840
Now, I want to re-emphasize that durable software engineering is not going away because this is the biggest confusion that I see on social media today.

s149
00:11:32.840 --> 00:11:44.080
In fact, I believe the absolute amount of durable software in the world will increase because AI coding tools make it easier and easier to make more durable software.

s150
00:11:44.080 --> 00:11:49.840
And another important thing to understand is that disposable and durable are not black and white.

s151
00:11:49.840 --> 00:11:59.040
There's a spectrum, like I showed before, but that spectrum what changes across the spectrum is how much effort you're going to put into engineering rigor.

s152
00:11:59.040 --> 00:11:59.680
Okay?

s153
00:11:59.680 --> 00:12:05.200
And that's both immediate effort and effort over time, just like we've always talked about for software.

s154
00:12:05.200 --> 00:12:15.440
However, what you want to do, and I think what you want to care about the most, is reducing the cost of effort, reducing the cost of rigor.

s155
00:12:15.440 --> 00:12:23.520
Like, if rigor is cheaper, if it's the the easier and easier you make it to be rigor, the less you have to worry about where you are on the scale.

s156
00:12:23.520 --> 00:12:26.760
So, this is another approach you can take.

s157
00:12:26.760 --> 00:12:33.360
If you change your mind, it's much easier to go like you're like, "Oh, I thought this was going to be disposable and now it needs to be durable."

s158
00:12:33.360 --> 00:12:43.000
The cheaper you make it to make it durable, the easier it is to change your mind or to be wrong because you're never going to be 100% right all the time on that estimate.

s159
00:12:43.000 --> 00:12:53.080
So, that involves a different set of practices that are not engineering rigor themselves, but that are about how to decrease the cost of engineering rigor.

s160
00:12:53.080 --> 00:12:54.839
Now, I could talk about this for hours.

s161
00:12:54.839 --> 00:12:58.000
I have spent a tremendous amount of my career doing this.

s162
00:12:58.000 --> 00:12:59.280
Uh I don't have 10 hours.

s163
00:12:59.280 --> 00:13:01.440
I have about 5 minutes left on that timer.

s164
00:13:01.440 --> 00:13:05.760
So, I'll tell I'll talk about what I can, okay?

s165
00:13:05.880 --> 00:13:07.480
Let's talk about standardization.

s166
00:13:07.480 --> 00:13:09.120
Why do we do standardization?

s167
00:13:09.120 --> 00:13:11.080
People are like, "Well, I don't know because the boss said so."

s168
00:13:11.080 --> 00:13:17.160
Well, now, we do standardization because it removes possibilities.

s169
00:13:17.160 --> 00:13:26.240
If you don't have any PHP in your system, you don't have to figure out what are all the linters for PHP, what are all the practices, what are all the security holes I have to fix.

s170
00:13:26.240 --> 00:13:32.600
You just eliminate possibilities through standardization and it just reduces the cost of rigor.

s171
00:13:32.600 --> 00:13:33.880
Uh same thing with like frameworks.

s172
00:13:33.880 --> 00:13:38.400
Like why don't you want to have every front-end framework or every back-end framework in the in existence?

s173
00:13:38.400 --> 00:13:40.400
Because it makes rigor more expensive.

s174
00:13:40.400 --> 00:13:41.600
Like yes, rigor is still possible.

s175
00:13:41.600 --> 00:13:46.000
Yes, you could still have the agent code up all your tools, but you have to do it every single time.

s176
00:13:46.000 --> 00:13:47.920
Uh you know, proto- uh protocols.

s177
00:13:47.920 --> 00:13:49.560
Why do you want to have standardized RPC protocols?

s178
00:13:49.560 --> 00:13:50.920
All the same thing.

s179
00:13:50.920 --> 00:13:52.920
Standards are all for this reason.

s180
00:13:52.920 --> 00:13:53.600
Okay?

s181
00:13:53.600 --> 00:13:55.440
Uh what I call inward flow tooling.

s182
00:13:55.440 --> 00:13:57.640
So, inward flow tooling is tooling that just occurs.

s183
00:13:57.640 --> 00:13:59.160
The programmer doesn't have to choose to run it.

s184
00:13:59.160 --> 00:14:01.000
They don't have to understand how it runs.

s185
00:14:01.000 --> 00:14:02.080
It just happens.

s186
00:14:02.080 --> 00:14:07.000
If it's there, it it's feels and seems free and it is reliable.

s187
00:14:07.000 --> 00:14:08.760
Reliability is very, very important.

s188
00:14:08.760 --> 00:14:10.680
Like it doesn't have a ton of false positives.

s189
00:14:10.680 --> 00:14:11.760
It's fast.

s190
00:14:11.760 --> 00:14:12.800
It just happens.

s191
00:14:12.800 --> 00:14:16.080
And the more that's true, like you can apply it to your disposable software, too.

s192
00:14:16.080 --> 00:14:18.960
If it's free and fast, who cares?

s193
00:14:18.960 --> 00:14:21.040
Uh making testing easier.

s194
00:14:21.040 --> 00:14:24.480
So, this is not just about like, "Hey, how do we do better testing?"

s195
00:14:24.480 --> 00:14:28.840
Look, how do you make it so that nobody has to think about how to do better testing?

s196
00:14:28.840 --> 00:14:35.920
How do you make it so that every test is fast and deterministic without anybody having to be a deep expert in testing?

s197
00:14:35.920 --> 00:14:41.320
There's a ton of work that you have to put into test infrastructure to make that possible.

s198
00:14:41.320 --> 00:14:51.520
For example, you know, one of the great dreams that I've always had as a as a test owner is that everybody would provide in-memory fake versions of their services and I could just run those in-memory fake versions of their services.

s199
00:14:51.520 --> 00:14:52.400
Guess what?

s200
00:14:52.400 --> 00:14:53.640
The coding agent can do that.

s201
00:14:53.640 --> 00:14:55.440
So, you can just do that now, right?

s202
00:14:55.440 --> 00:14:58.920
But you have to choose to do it and make it available to everybody.

s203
00:14:58.920 --> 00:15:02.040
And another thing is, look, maximum strictness.

s204
00:15:02.040 --> 00:15:03.520
You just turn the strictness up everywhere.

s205
00:15:03.520 --> 00:15:06.120
You turn You set all your lint rules to maximum.

s206
00:15:06.120 --> 00:15:11.280
You You never compromise on anything and it just eliminates It's very similar to standardization.

s207
00:15:11.280 --> 00:15:12.800
It eliminates a ton of conversations.

s208
00:15:12.800 --> 00:15:13.920
Sometimes the lint is wrong.

s209
00:15:13.920 --> 00:15:23.120
Like as long as the false positive rate is relatively low and it doesn't have catastrophic consequences, it doesn't matter because all of a sudden there's a bunch of future lint errors or future issues that you don't have to deal with.

s210
00:15:23.120 --> 00:15:28.240
Like, ask anybody who's been like, "Oh, I suddenly want to turn on my linter in this million-line code base."

s211
00:15:28.240 --> 00:15:29.560
And they're like, "Oh, wow.

s212
00:15:29.560 --> 00:15:32.960
Now here's my 100,000-line change that I need to make, right?"

s213
00:15:32.960 --> 00:15:35.520
Much easier to just do that up front and have it on for everybody.

s214
00:15:35.520 --> 00:15:36.640
Now, look.

s215
00:15:36.640 --> 00:15:40.720
Like I said, I could literally stand here and talk to you about this straight for 10 hours.

s216
00:15:40.720 --> 00:15:43.200
There is much, much more you can do here.

s217
00:15:43.200 --> 00:15:49.360
This is just a few areas, but also a whole area of software engineering discipline that you can apply on the other axis.

s218
00:15:49.360 --> 00:15:59.840
So, this lets us now answer our question, not just it depends, but yes or no. So, does code quality even matter?

s219
00:15:59.840 --> 00:16:06.280
For disposable software, no. For durable software, yes.

s220
00:16:06.280 --> 00:16:12.720
And we get to answer a third and even more interesting question, which is does it have to be expensive?

s221
00:16:12.720 --> 00:16:15.961
No. Thank you very much.

s222
00:16:15.961 --> 00:16:17.271
[applause]

s223
00:16:17.271 --> 00:16:19.271
[music]