Look this isn’t at all a defense of slop code, but it has me thinking — how much does code quality matter, and why?

It’s maintenance, right? We care about readability because we know we’ll have to make changes, fix bugs, etc.

But so … imagine a codebase that’s magically bug-free and feature-complete. (I’m aware this is a strawman - that’s the point, it’s a thought experiment.) Does it matter if this codebase is well-written? I’m not sure it does! (1/5)

Code quality has always been ONE factor; it’s never been always the most important. Eg we often accept complex internals as the price for a clean external API; and we all write sloppy code for one-offs, prototypes, etc. So part of me accepts the “code quality doesn’t matter” argument. I can see a vision of agentic engineering with systems that prove correctness; if an agent produces code that is provably correct, maybe the quality really doesn’t matter! (2/5)
I’m far from convinced that this is actually possible. It’s certainly not now — and I’m not talking about models. Testing and verification tools are nowhere near where they’d need to be, regardless of model quality. Today, code quality DOES still matter; even the best-case version of agentic engineering can’t produce code that’ll never require maintenance. But I can see a possible future where code quality might not matter, or will matter a lot less, and that’s FASCINATING. (3/5)
Specifically what I find fascinating is: the tooling that would be required to make agentic engineering begin to live up to the hype — much better testing tools, formal business logic specification languages, more powerful and easier to use formal verification tools, better static analysis tooling, etc — would be massively useful to software engineering quite regardless of the existence/utility/quality of LLMs. (4/5)
Will we actually build them? I sort of doubt it: the history of software development, and of course the current trajectory, suggests we’ll continue to yolo our way through it. I wouldn’t exactly say I’m optimistic, but hope springs eternal. (5/5)
@jacob I think this is a subtle category error, in the sense that "readability" (and "code quality" more generally) is a transitive adjective. Readable to whom? High quality according to whose taste? We strive for an "objective" sense of code quality because the audience we are usually addressing is the pool of potential candidates who may become future maintainers of the code, and that's a nebulous group. But, that group's nebulousness eventually must be removed as it becomes "the current team"
@jacob all of that is to say: the reason readability matters is that if you want to maintain some code, some specific group of humans must maintain an understanding of its structure, such that they can effectuate *and be held accountable for* required changes. The putative cost reduction of an "agentic" tool inherently assumes that you can shrink that group by replacing some of them with LLMs. Maybe, eventually, some will be able to. But ultimately *somebody* still needs to read all the code.
@jacob the world in which agentic tools could have the level of success that you're imagining with trash-level code quality would seem to me to be the same world where anyone annoyed with a subscription-model app would simply download a 30-year-old abandonware replacement from archive dot org, because they'd be comfortable with long-term stasis. which seems unrealistic to me.
@glyph Yeah, that’s one conclusion I’m coming to thanks to this discussion. I was aware of the slipperiness of “quality”, and was kinda doing that deliberately because exploring weather quality matters is (to me) more interesting than defining quality precisely. But what I hadn’t noticed was that “done” was just as slippery — and in order for quality (whatever definition) not to matter, there has to be no maintenance, and that requires “done” to actually be a thing.
@glyph (Tho - I think software engineering would be in a better place if “done” was more common. Like, is 80% of the TCO of a bridge in maintenance? I sort of doubt it. There are times when I think that calling it software “engineering” is a bit of a joke.)
@jacob @glyph I prefer to think of it as aspirational.
@jacob @glyph calling it software engineering is absolutely a joke, it has been a joke for a while, and the rush to adopt LLMs and mostly not read their output is probably the strongest evidence we have that it's been a joke.
Reverse ungineering

(Title with apologies to Glyph.) Recently, some friends of mine suggested that "software engineer" is not a good job title. While they are of course free to call their profession whatever they like, I

lvh
@glyph @fancysandwiches @jacob (One of my university courses was called "Software Construction", and I unironically like it as an all-encompassing term. There _is_ engineering there, but not everyone needs to be/think/at like an engineer.)
@chrisjrn @glyph @jacob yeah that seems appropriate to me. I just refer to people as software developers. We're developing software, we're not engineering it (for the most part, there are some folks taking stuff incredibly seriously).

@jacob this specific question is really interesting and my hunch was that it would be a surprisingly high %, so, let's see:

https://en.as.com/latest_news/when-was-san-franciscos-golden-gate-bridge-built-and-how-much-did-it-cost-n/#:~:text=The%20Golden%20Gate%20Bridge%20in%20San%20Francisco%20was%20constructed%20from%20January%201933%20to%20May%201937.%20The%20project%20cost%20approximately%20$35%20million%2C%20which%20is%20equivalent%20to%20around%20$666%20million%20in%20today’s%20dollars. says the golden gate cost $35MM ($666MM inflation-adjusted for 2024) to build; https://www.sfchronicle.com/bayarea/article/s-f-golden-gate-bay-bridge-operate-costs-18221920.php claims $103MM to operate in 2024. If we were to just flatten that out, that would put the maintenance share of the TCO at 93% as of this writing :)

When was San Francisco’s Golden Gate Bridge built and how much did it cost?

The bridge’s construction was a significant achievement in engineering and architecture and continues to be an important part of the city’s identity.

AS USA
@jacob I suspect that this is not really a fair way to measure this sort of expense but it's still a counterintuitive back-of-the-envelope calculation!