Machine transcription with reviewed terminology and names. Some recognition errors may remain. Timestamps refer to the livestream; subtitle downloads are timed to the session clips.
0:43:52All right.
0:43:53So today I figured I'd pick a nice uncontroversial topic that nobody has any opinions about.
0:43:59Right?
0:44:00Nobody has said anything on this about social media.
0:44:04And of course every take about this on social media is really deeply nuanced.
0:44:10People have lots of depth and really big thoughts.
0:44:13You know, maybe there's a little bit more to it than like yes or no.
0:44:18And, you know, of course, if you ever ask a senior engineer a question, we always have
0:44:22the same answer to every question, every senior engineer's favorite answer to every question,
0:44:26which is, it depends.
0:44:30Now, that's not a very helpful answer, though, frankly, because what does it depend on?
0:44:36So let's start with this.
0:44:38Why did code quality ever matter in the first place?
0:44:41I see a lot of people be like, well, it made me feel good.
0:44:44That's not really a sufficient justification.
0:44:46So let's see if we can inject some nuance into this conversation and help everybody at
0:44:50least be able to have a basis for reasoning about it while we're discussing it.
0:44:54So let's see if we can make a framework here.
0:44:56That's what we're going to try to do with this talk.
0:44:59So we're going to start off with everything you want to ever accomplish with a piece of
0:45:02software depends on two factors and two factors alone.
0:45:06And that is understanding and executing on that understanding.
0:45:09Whether that's aligning a model, scaling a system, driving adoption, anything, all software
0:45:14success is determined by these two factors.
0:45:17This is why we have things like debuggers and observability and evals and even tests.
0:45:21All those things actually are there to improve your understanding or ability to execute on
0:45:25that understanding.
0:45:25People think that they're there for other reasons, but fundamentally they're there for that reason.
0:45:30Everything we have ever done in the field of code quality is exclusively and only for
0:45:36these two things.
0:45:37It's not for anything else.
0:45:39And that doesn't have something to do with correctness or something else.
0:45:41It has to do only with these two things.
0:45:44Now, there's two understandings that are the most important to have
0:45:46if you're going to be a software engineer.
0:45:48There are other understandings to have about software,
0:45:50if you're going to be a product, if you're going to be in sales.
0:45:52But if you're a software engineer, there's the two that are the most important.
0:45:55And the first is, what is the behavior of the system?
0:45:58Like, concretely, not what does a doc say the behavior of the system is,
0:46:02but what is the actual behavior of the system?
0:46:04And the second one is, how do I correctly and safely modify that behavior?
0:46:11On a very small system, if you want to understand what the system does,
0:46:16I just tell you what it does.
0:46:18It prints hello world.
0:46:19You say, I wanted to say hi world.
0:46:21I say, okay, I will make it say hi world now.
0:46:23There's very little to understand about it other than purely what it does.
0:46:28That's all of the understanding that you need.
0:46:30However, any real software system is enormously complex.
0:46:34This is a real map of the code base of Chromium,
0:46:39which is the open source project behind Chrome.
0:46:42And if you think about all of the different ways
0:46:45that these components can interact,
0:46:46they have essentially infinite possible behaviors.
0:46:50Like, I could not describe to you in words
0:46:53the behavior of Chromium as a whole, as a system.
0:46:58However, what I can describe to you, and as we all know, everybody's been a software engineer
0:47:02for a while, I can describe to you components of the system.
0:47:06I can successfully describe to you how a component of the system behaves.
0:47:11So this is the URL parser, the actual functions and stuff for the URL parser of Chromium.
0:47:16It figures out all the different parts of the URL.
0:47:19And this is the whole reason that code exists.
0:47:25The whole reason that we have code at all in the first place is for structure.
0:47:32What do I mean by that?
0:47:35Both of these two things on the left and on the right will print Hello World if run on
0:47:40a Linux machine.
0:47:42However, on the left you can see that it is Hello World.
0:47:46It has the identity and structure of Hello World.
0:47:50On the right, you just see a series of instructions with no particular identity, recognizable
0:47:55or understandable identity.
0:47:57It's not a component.
0:47:58It's just a bunch of instructions.
0:48:00While that's understandable there, if that was millions or billions of lines of that,
0:48:04it would be much harder to grok.
0:48:06In the past, we've talked about things like readability or testability or things that
0:48:11seemed like human concepts about code.
0:48:14But what actually mattered the most always was that the system had some sort of understandable
0:48:19structure.
0:48:19So it's the structure that actually matters.
0:48:23And when this matters the most is when you want to modify the system, the second understanding
0:48:30that we talked about.
0:48:32All modifications to a system carry two categories of risk.
0:48:35The first is that you will introduce some sort of problem.
0:48:38And a problem isn't just a bug, it's anything bad that could happen.
0:48:42Like your project could take much longer than you expect.
0:48:44It could not behave in the way that you wanted it to for your users.
0:48:48The project could fail because you have budget overruns.
0:48:50Any kind of problem could happen from just you trying to go through the process of making this change.
0:48:55And the second is you could make it harder to make future changes.
0:49:00In particular, what that means is you could make it more likely to have future problems.
0:49:03You could increase future risk of the system.
0:49:06These two things are caused by problems with understanding.
0:49:12So the first has to do with the difficulty of understanding the system in the first place.
0:49:17And the second is you make the system harder to understand.
0:49:21can reduce every post-mortem I have ever read for any incident to these two factors
0:49:27in one way or another.
0:49:29The production configuration was too hard to understand.
0:49:31Somebody made something impossible to understand.
0:49:33There were emergent properties of the system that were impossible to understand.
0:49:36Whatever.
0:49:37Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion.
0:49:47So the difficulty of understanding does not grow linearly, it compounds over time.
0:49:52You will eventually reach a point, and all systems eventually tend to reach this point,
0:49:57where every modification involves some sort of problem.
0:50:04Some systems get to the point where you can't modify them at, if you think of your giant
0:50:10100 million, 500 million line mainframe code bases, everything, every change is some sort
0:50:16of problem.
0:50:16You'll see it in organizational issues, you'll see it all over the place, you'll see it in
0:50:20timelines, whatever.
0:50:22And look, there's a lot of arguments about maybe future models will fix this.
0:50:25Look, maybe they will, maybe future models will have infinite ability to deal with complexity
0:50:29somehow.
0:50:30But we don't have to discuss that today because I think models are doing something else really
0:50:35interesting right now.
0:50:37They are creating a new kind of software, a new category of software.
0:50:42This category has always existed, but it's about to become 100,000 times more common
0:50:49than any other form of software, and that is disposable software.
0:50:56So what is that?
0:50:58Okay, so imagine a world in which the consequences of failure for your system are very minimal
0:51:04or nonexistent.
0:51:06Imagine that there's very few people that depend on it, and almost no other systems depend
0:51:10on that piece of software.
0:51:12Change management, very minimal, non-existent.
0:51:15Imagine the cost of replacement went to near zero.
0:51:19You could replace the whole thing in hours or days.
0:51:22And it had basically no cost of maintenance.
0:51:25In that world, code quality does not matter.
0:51:32Because all of those things we were trying to prevent
0:51:35about the compounding risks over time don't exist.
0:51:41Traditionally, we've always built durable software.
0:51:45lives for years, it's depended on millions or thousands of people, there's huge consequences
0:51:50of failure, potentially business catastrophic consequences of failure, and it requires enormous
0:51:55maintenance.
0:51:56Most of the software engineers in the world spend most of their time maintaining these
0:52:00giant durable systems.
0:52:02I expect this to continue to exist.
0:52:05So this is one of the areas where I think sometimes the conversation goes a little astray.
0:52:10Durable systems will continue to probably be the most important systems in the world.
0:52:17And there will be probably more of them.
0:52:20But the most numerous systems will be disposable software.
0:52:26They will be replaceable in hours.
0:52:28They will be depended on by a few.
0:52:29Or change management just won't matter.
0:52:31And look, if it doesn't work, we'll give everybody agents.
0:52:35They'll make a version of it themselves.
0:52:38Maintenance will be unimportant or nearly free.
0:52:40Don't like the calculator on your OS?
0:52:42Make your own.
0:52:43Want to plan a party for your kids?
0:52:45Write a party planner software just for that one party.
0:52:49Throw it away.
0:52:50Code quality doesn't matter.
0:52:51Nobody cares.
0:52:53In the future, we will apply engineering rigor to the degree of disposability of the software.
0:53:00On the left, nothing, none of our practices of engineering rigor matter at all.
0:53:06On the right, all the practices of engineering that we have built up over the last many decades
0:53:11matter greatly.
0:53:12We can determine where you are on this scale by those four factors that I have been talking
0:53:17about.
0:53:18Consequences, cost of replacement, dependencies, and cost of maintenance.
0:53:22If they're all low, it's
0:53:23disposable software. If they're all high, it's durable software.
0:53:27And 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.
0:53:36But there's also a new thing you can do in the world. You can make software more disposable. So, like, what does that involve?
0:53:46Well, come up with better isolated environments.
0:53:50So, hey, you can only deploy to this environment that has access to only your data.
0:53:54No customer data, no personally identifiable information, whatever.
0:53:58You can enforce independence.
0:54:00You can say, okay, no inbound API calls from other production systems are allowed to this
0:54:06system in this environment.
0:54:07And so everything deployed to that environment is disposable.
0:54:11Redundancy.
0:54:11You can have an old clunky backup system that is hard to use.
0:54:16And then, look, if people want to vibe code their own more efficient front ends,
0:54:19you let them vibe code their own more efficient front ends
0:54:21because there is an old, durable, clunky backup system that they can use
0:54:25if their crappy little vibe-coded thing fails.
0:54:28Which it will fail. That's fine. But it doesn't matter if it fails.
0:54:32And you can limit scope, just like I talked about.
0:54:34It's just a calculator for this one person.
0:54:36It just plans this one party.
0:54:38There's so much more we could do here and talk about ways of increasing disposability.
0:54:45In fact, I think this is a whole new discipline of software engineering.
0:54:50Not to think about how we improve the rigor of durable systems, but how do we take our
0:54:55systems and how do we encourage disposability or allow more disposability, allow people
0:55:00to throw these things away.
0:55:02Interesting thought.
0:55:03Now, I want to re-emphasize that durable software engineering is not going away because this
0:55:10is the biggest confusion that I see on social media today.
0:55:14In fact, I believe the absolute amount of durable software in the world will increase
0:55:18because AI coding tools make it easier and easier to make more durable software.
0:55:25another important thing to understand is that disposable and durable are not black
0:55:30and white.
0:55:31There's a spectrum, like I showed before, but that spectrum, what changes across the
0:55:35spectrum is how much effort you're going to put into engineering rigor.
0:55:39Okay?
0:55:40And that's both immediate effort and effort over time, just like we've always talked about
0:55:44for software.
0:55:46However, what you want to do, and I think what you want to care about the most, is reducing
0:55:51the cost of effort.
0:55:53Reducing the cost of rigor.
0:55:56like if rigor is cheaper if it's the easier and easier you make it to be rigor the less you have
0:56:02to worry about where you are on the scale so this is another approach you can take
0:56:07if you change your mind it's much easier to like you're like oh i thought this was going to be
0:56:12disposable and now it needs to be durable the cheaper you make it to make it durable the easier
0:56:17it is to change your mind or to be wrong because you're never going to be 100 right all the time
0:56:22on that estimate. So that involves a different set of practices that are not engineering
0:56:27rigor themselves, but that are about how to decrease the cost of engineering rigor.
0:56:34Now, I could talk about this for hours. I have spent a tremendous amount of my career
0:56:38doing this. I don't have 10 hours. I have about five minutes left on that timer. So
0:56:43I'll talk about what I can, okay? Let's talk about standardization. Why do we do standardization?
0:56:50People are like, well, I don't know, because the boss said so.
0:56:52Well, no.
0:56:54We do standardization because it removes possibilities.
0:56:58If you don't have any PHP in your system,
0:57:01you don't have to figure out what are all the linters for PHP,
0:57:04what are all the practices, what are all the security holes I have to fix.
0:57:07You just eliminate possibilities through standardization,
0:57:10and it just reduces the cost of rigor.
0:57:13Same thing with frameworks.
0:57:15Why don't you want to have every front-end framework
0:57:17or every back-end framework in existence?
0:57:19because it makes rigor more expensive.
0:57:21Like, yes, rigor is still possible.
0:57:22Yes, you could still have the agent code up all your tools,
0:57:24but you have to do it every single time.
0:57:27You know, protocols,
0:57:29why do you want to have standardized RPC protocols?
0:57:30All the same thing.
0:57:32Standards are all for this reason.
0:57:34Okay?
0:57:35What I call in-workflow tooling.
0:57:36So in-workflow tooling is tooling that just occurs.
0:57:38The programmer doesn't have to choose to run it.
0:57:40They don't have to understand how it runs.
0:57:42It just happens.
0:57:43If it's there, it feels and seems free,
0:57:46and it is reliable.
0:57:48Reliability is very, very important.
0:57:50It doesn't have a ton of false positives.
0:57:51It's fast. It just happens.
0:57:54And the more that's true, you can apply it to your disposable software too.
0:57:57If it's free and fast, who cares?
0:58:01Making testing easier.
0:58:02So this is not just about, like, hey, how do we do better testing?
0:58:05Look, how do you make it so that nobody has to think about how to do better testing?
0:58:09How do you make it so that every test is fast and deterministic
0:58:14without anybody having to be a deep expert in testing?
0:58:16There's a ton of work that you have to put into test infrastructure to make that possible.
0:58:22For example, one of the great dreams that I've always had as a test owner is that everybody
0:58:27would provide in-memory fake versions of their services and I could just run those in-memory
0:58:31fake versions of their services.
0:58:32Guess what?
0:58:33The coding agent can do that.
0:58:34So you can just do that now.
0:58:36But you have to choose to do it and make it available to everybody.
0:58:40And another thing is, look, maximum strictness.
0:58:43You just turn the strictness up everywhere.
0:58:44You set all your lint rules to maximum.
0:58:47You never compromise on anything.
0:58:49And it eliminates, it's very similar to standardization.
0:58:52It eliminates a ton of conversations.
0:58:54Sometimes the linter is wrong.
0:58:55As long as the false positive rate is relatively low and doesn't have catastrophic consequences,
0:58:58it doesn't matter because all of a sudden there's a bunch of future lint errors or future
0:59:03issues that you don't have to deal with.
0:59:04Ask anybody who's been like, oh, I suddenly want to turn on my linter in this million
0:59:08line code base.
0:59:09And they're like, oh, wow.
0:59:10Now here's my 100,000 line change that I need to make.
0:59:13Much easier to do that up front and have it on for everybody.
0:59:16Now look, like I said, I could literally stand here and talk to you about this straight for
0:59:21ten hours.
0:59:21There is much, much more you can do here.
0:59:24This is just a few areas, but also a whole area of software engineering discipline that
0:59:28you can apply on the other axis.
0:59:31So this lets us now answer our question, not just it depends, but yes or no.
0:59:37So does code quality even matter?
0:59:40For disposable software, no.
0:59:44For durable software, yes.
0:59:47And we get to answer a third and even more interesting question,
0:59:50which is, does it have to be expensive?
0:59:53No.
0:59:54Thank you very much.
