Does Code Quality Even Matter?

1:10:28All right.

1:10:30So today I figured I'd pick a nice uncontroversial topic that nobody has any opinions about.

1:10:35Right?

1:10:36Nobody has said anything on this about social media.

1:10:40And of course every take about this on social media is really deeply nuanced.

1:10:46People have lots of depth and really big thoughts.

1:10:49You know, maybe there's a little bit more to it than like yes or no.

1:10:54And, you know, of course, if you ever ask a senior engineer a question, we always have

1:10:58the same answer to every question, every senior engineer's favorite answer to every question,

1:11:02which is, it depends.

1:11:06Now, that's not a very helpful answer, though, frankly, because what does it depend on?

1:11:12So let's start with this.

1:11:15Why did code quality ever matter in the first place?

1:11:17I see a lot of people be like, well, it made me feel good.

1:11:20That's not really a sufficient justification.

1:11:22So let's see if we can inject some nuance into this conversation and help everybody at

1:11:27least be able to have a basis for reasoning about it while we're discussing it.

1:11:30So let's see if we can make a framework here.

1:11:32That's what we're going to try to do with this talk.

1:11:35So we're going to start off with everything you want to ever accomplish with a piece of

1:11:39software depends on two factors and two factors alone.

1:11:42And that is understanding and executing on that understanding.

1:11:45Whether that's aligning a model, scaling a system, driving adoption, anything, all software

1:11:50success is determined by these two factors.

1:11:53This is why we have things like debuggers and observability and evals and even tests.

1:11:58All those things actually are there to improve your understanding or ability to execute on

1:12:01that understanding.

1:12:02People think that they're there for other reasons, but fundamentally they're there for that reason.

1:12:06Everything we have ever done in the field of code quality is exclusively and only for

1:12:13these two things.

1:12:14It's not for anything else.

1:12:15And that doesn't have something to do with correctness or something else.

1:12:17It has to do only with these two things.

1:12:20Now, there's two understandings that are the most important to have

1:12:23if you're going to be a software engineer.

1:12:24There are other understandings to have about software,

1:12:27if you're going to be a product, if you're going to be in sales.

1:12:29But if you're a software engineer, there's the two that are the most important.

1:12:31And the first is, what is the behavior of the system?

1:12:35Like, concretely, not what does a doc say the behavior of the system is,

1:12:38but what is the actual behavior of the system?

1:12:40And the second one is, how do I correctly and safely modify that behavior?

1:12:47On a very small system, if you want to understand what the system does,

1:12:52I just tell you what it does.

1:12:54It prints hello world.

1:12:55You say, I wanted to say hi world.

1:12:57I say, okay, I will make it say hi world now.

1:13:00There's very little to understand about it other than purely what it does.

1:13:04That's all of the understanding that you need.

1:13:06However, any real software system is enormously complex.

1:13:10This is a real map of the code base of Chromium,

1:13:15which is the open source project behind Chrome.

1:13:18And if you think about all of the different ways

1:13:21that these components can interact,

1:13:23they have essentially infinite possible behaviors.

1:13:26Like, I could not describe to you in words

1:13:29the behavior of Chromium as a whole, as a system.

1:13:34However, what I can describe to you, and as we all know, everybody's been a software engineer

1:13:39for a while, I can describe to you components of the system.

1:13:42I can successfully describe to you how a component of the system behaves.

1:13:47So this is the URL parser, the actual functions and stuff for the URL parser of Chromium.

1:13:52It figures out all the different parts of the URL.

1:13:56And this is the whole reason that code exists.

1:14:01The whole reason that we have code at all in the first place is for structure.

1:14:08What do I mean by that?

1:14:12Both of these two things on the left and on the right will print Hello World if run on

1:14:17a Linux machine.

1:14:18However, on the left you can see that it is Hello World.

1:14:23It has the identity and structure of Hello World.

1:14:26On the right, you just see a series of instructions with no particular identity, recognizable

1:14:32or understandable identity.

1:14:33It's not a component.

1:14:34It's just a bunch of instructions.

1:14:36While that's understandable there, if that was millions or billions of lines of that,

1:14:40it would be much harder to grok.

1:14:42In the past, we've talked about things like readability or testability or things that

1:14:48seemed like human concepts about code.

1:14:50But what actually mattered the most always was that the system had some sort of understandable

1:14:55structure.

1:14:56So it's the structure that actually matters.

1:14:59And when this matters the most is when you want to modify the system, the second understanding

1:15:06that we talked about.

1:15:08All modifications to a system carry two categories of risk.

1:15:11The first is that you will introduce some sort of problem.

1:15:14And a problem isn't just a bug, it's anything bad that could happen.

1:15:18Like your project could take much longer than you expect.

1:15:21It could not behave in the way that you wanted it to for your users.

1:15:24The project could fail because you have budget overruns.

1:15:27Any kind of problem could happen from just you trying to go through the process of making this change.

1:15:32And the second is you could make it harder to make future changes.

1:15:36In particular, what that means is you could make it more likely to have future problems.

1:15:39You could increase future risk of the system.

1:15:42These two things are caused by problems with understanding.

1:15:48So the first has to do with the difficulty of understanding the system in the first place.

1:15:53And the second is you make the system harder to understand.

1:15:58can reduce every post-mortem I have ever read for any incident to these two factors

1:16:03in one way or another.

1:16:05The production configuration was too hard to understand.

1:16:08Somebody made something impossible to understand.

1:16:09There were emergent properties of the system that were impossible to understand.

1:16:12Whatever.

1:16:13Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion.

1:16:23So the difficulty of understanding does not grow linearly, it compounds over time.

1:16:28You will eventually reach a point, and all systems eventually tend to reach this point,

1:16:33where every modification involves some sort of problem.

1:16:40Some systems get to the point where you can't modify them at, if you think of your giant

1:16:47100 million, 500 million line mainframe code bases, everything, every change is some sort

1:16:52of problem.

1:16:53You'll see it in organizational issues, you'll see it all over the place, you'll see it in

1:16:56timelines, whatever.

1:16:58And look, there's a lot of arguments about maybe future models will fix this.

1:17:02Look, maybe they will, maybe future models will have infinite ability to deal with complexity

1:17:05somehow.

1:17:07But we don't have to discuss that today because I think models are doing something else really

1:17:12interesting right now.

1:17:13They are creating a new kind of software, a new category of software.

1:17:18This category has always existed, but it's about to become 100,000 times more common

1:17:26than any other form of software, and that is disposable software.

1:17:32So what is that?

1:17:34Okay, so imagine a world in which the consequences of failure for your system are very minimal

1:17:41or nonexistent.

1:17:42Imagine that there's very few people that depend on it, and almost no other systems depend

1:17:47on that piece of software.

1:17:48Change management, very minimal, non-existent.

1:17:52Imagine the cost of replacement went to near zero.

1:17:56You could replace the whole thing in hours or days.

1:17:58And it had basically no cost of maintenance.

1:18:01In that world, code quality does not matter.

1:18:08Because all of those things we were trying to prevent

1:18:11about the compounding risks over time don't exist.

1:18:17Traditionally, we've always built durable software.

1:18:22lives for years, it's depended on millions or thousands of people, there's huge consequences

1:18:26of failure, potentially business catastrophic consequences of failure, and it requires enormous

1:18:31maintenance.

1:18:32Most of the software engineers in the world spend most of their time maintaining these

1:18:36giant durable systems.

1:18:38I expect this to continue to exist.

1:18:41So this is one of the areas where I think sometimes the conversation goes a little astray.

1:18:46Durable systems will continue to probably be the most important systems in the world.

1:18:54And there will be probably more of them.

1:18:56But the most numerous systems will be disposable software.

1:19:02They will be replaceable in hours.

1:19:04They will be depended on by a few.

1:19:06Or change management just won't matter.

1:19:08And look, if it doesn't work, we'll give everybody agents.

1:19:11They'll make a version of it themselves.

1:19:14Maintenance will be unimportant or nearly free.

1:19:16Don't like the calculator on your OS?

1:19:18Make your own.

1:19:19Want to plan a party for your kids?

1:19:21Write a party planner software just for that one party.

1:19:26Throw it away.

1:19:27Code quality doesn't matter.

1:19:27Nobody cares.

1:19:29In the future, we will apply engineering rigor to the degree of disposability of the software.

1:19:36On the left, nothing, none of our practices of engineering rigor matter at all.

1:19:42On the right, all the practices of engineering that we have built up over the last many decades

1:19:47matter greatly.

1:19:49We can determine where you are on this scale by those four factors that I have been talking

1:19:54about.

1:19:55Consequences, cost of replacement, dependencies, and cost of maintenance.

1:19:58If they're all low, it's

1:20:00disposable software. If they're all high, it's durable software.

1:20:03And 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.

1:20:12But there's also a new thing you can do in the world. You can make software more disposable. So, like, what does that involve?

1:20:22Well, come up with better isolated environments.

1:20:26So, hey, you can only deploy to this environment that has access to only your data.

1:20:30No customer data, no personally identifiable information, whatever.

1:20:34You can enforce independence.

1:20:37You can say, okay, no inbound API calls from other production systems are allowed to this

1:20:42system in this environment.

1:20:43And so everything deployed to that environment is disposable.

1:20:47Redundancy.

1:20:47You can have an old clunky backup system that is hard to use.

1:20:52And then, look, if people want to vibe code their own more efficient front ends,

1:20:55you let them vibe code their own more efficient front ends

1:20:57because there is an old, durable, clunky backup system that they can use

1:21:01if their crappy little vibe-coded thing fails.

1:21:04Which it will fail. That's fine. But it doesn't matter if it fails.

1:21:08And you can limit scope, just like I talked about.

1:21:10It's just a calculator for this one person.

1:21:13It just plans this one party.

1:21:14There's so much more we could do here and talk about ways of increasing disposability.

1:21:21In fact, I think this is a whole new discipline of software engineering.

1:21:26Not to think about how we improve the rigor of durable systems, but how do we take our

1:21:32systems and how do we encourage disposability or allow more disposability, allow people

1:21:37to throw these things away.

1:21:38Interesting thought.

1:21:39Now, I want to re-emphasize that durable software engineering is not going away because this

1:21:46is the biggest confusion that I see on social media today.

1:21:50In fact, I believe the absolute amount of durable software in the world will increase

1:21:54because AI coding tools make it easier and easier to make more durable software.

1:22:01another important thing to understand is that disposable and durable are not black

1:22:06and white.

1:22:07There's a spectrum, like I showed before, but that spectrum, what changes across the

1:22:11spectrum is how much effort you're going to put into engineering rigor.

1:22:16Okay?

1:22:17And that's both immediate effort and effort over time, just like we've always talked about

1:22:20for software.

1:22:22However, what you want to do, and I think what you want to care about the most, is reducing

1:22:27the cost of effort.

1:22:30Reducing the cost of rigor.

1:22:33like if rigor is cheaper if it's the easier and easier you make it to be rigor the less you have

1:22:38to worry about where you are on the scale so this is another approach you can take

1:22:44if you change your mind it's much easier to like you're like oh i thought this was going to be

1:22:48disposable and now it needs to be durable the cheaper you make it to make it durable the easier

1:22:53it is to change your mind or to be wrong because you're never going to be 100 right all the time

1:22:58on that estimate. So that involves a different set of practices that are not engineering

1:23:04rigor themselves, but that are about how to decrease the cost of engineering rigor.

1:23:10Now, I could talk about this for hours. I have spent a tremendous amount of my career

1:23:14doing this. I don't have 10 hours. I have about five minutes left on that timer. So

1:23:19I'll talk about what I can, okay? Let's talk about standardization. Why do we do standardization?

1:23:26People are like, well, I don't know, because the boss said so.

1:23:28Well, no.

1:23:30We do standardization because it removes possibilities.

1:23:34If you don't have any PHP in your system,

1:23:37you don't have to figure out what are all the linters for PHP,

1:23:40what are all the practices, what are all the security holes I have to fix.

1:23:43You just eliminate possibilities through standardization,

1:23:46and it just reduces the cost of rigor.

1:23:50Same thing with frameworks.

1:23:51Why don't you want to have every front-end framework

1:23:53or every back-end framework in existence?

1:23:55because it makes rigor more expensive.

1:23:58Like, yes, rigor is still possible.

1:23:59Yes, you could still have the agent code up all your tools,

1:24:01but you have to do it every single time.

1:24:03You know, protocols,

1:24:05why do you want to have standardized RPC protocols?

1:24:07All the same thing.

1:24:08Standards are all for this reason.

1:24:10Okay?

1:24:11What I call in-workflow tooling.

1:24:13So in-workflow tooling is tooling that just occurs.

1:24:15The programmer doesn't have to choose to run it.

1:24:16They don't have to understand how it runs.

1:24:18It just happens.

1:24:19If it's there, it feels and seems free,

1:24:22and it is reliable.

1:24:24Reliability is very, very important.

1:24:26It doesn't have a ton of false positives.

1:24:28It's fast. It just happens.

1:24:30And the more that's true, you can apply it to your disposable software too.

1:24:33If it's free and fast, who cares?

1:24:37Making testing easier.

1:24:38So this is not just about, like, hey, how do we do better testing?

1:24:42Look, how do you make it so that nobody has to think about how to do better testing?

1:24:46How do you make it so that every test is fast and deterministic

1:24:50without anybody having to be a deep expert in testing?

1:24:53There's a ton of work that you have to put into test infrastructure to make that possible.

1:24:58For example, one of the great dreams that I've always had as a test owner is that everybody

1:25:03would provide in-memory fake versions of their services and I could just run those in-memory

1:25:07fake versions of their services.

1:25:09Guess what?

1:25:09The coding agent can do that.

1:25:11So you can just do that now.

1:25:12But you have to choose to do it and make it available to everybody.

1:25:16And another thing is, look, maximum strictness.

1:25:19You just turn the strictness up everywhere.

1:25:21You set all your lint rules to maximum.

1:25:23You never compromise on anything.

1:25:25And it eliminates, it's very similar to standardization.

1:25:28It eliminates a ton of conversations.

1:25:30Sometimes the linter is wrong.

1:25:31As long as the false positive rate is relatively low and doesn't have catastrophic consequences,

1:25:35it doesn't matter because all of a sudden there's a bunch of future lint errors or future

1:25:39issues that you don't have to deal with.

1:25:40Ask anybody who's been like, oh, I suddenly want to turn on my linter in this million

1:25:45line code base.

1:25:45And they're like, oh, wow.

1:25:47Now here's my 100,000 line change that I need to make.

1:25:50Much easier to do that up front and have it on for everybody.

1:25:53Now look, like I said, I could literally stand here and talk to you about this straight for

1:25:57ten hours.

1:25:58There is much, much more you can do here.

1:26:00This is just a few areas, but also a whole area of software engineering discipline that

1:26:04you can apply on the other axis.

1:26:07So this lets us now answer our question, not just it depends, but yes or no.

1:26:13So does code quality even matter?

1:26:16For disposable software, no.

1:26:20For durable software, yes.

1:26:23And we get to answer a third and even more interesting question,

1:26:26which is, does it have to be expensive?

1:26:29No.

1:26:31Thank you very much.