Dave Farley gives a definition of code quality that kind of kicks the can down the road, and at the same time has little value except in hindsight. "If it's easy to change, it's high quality; if it's hard to change, it's not." But "easy to change" defies easy definition and measurement just as much as "quality" does. If we don't discover (or judge) code to have low quality until we need to change it, how does that help us write quality code to begin with?
How easy or hard a programmer thinks changing some code might get depends mainly on the programmer. An inexperienced programmer will find most code hard to read and change (and thus low quality by Farley's definition), whereas an experienced and skilled programmer will not have the same difficulty. A skills issue, in other words.
As programmers gain experience they usually internalize a vague set of heuristics by which they judge code quality. At the same time the range of code they can read and confidently change expands. Some programmers will get stuck in the "expert beginner" loop [1] and stop improving. Some programmers get hung up on aesthetic trivia and dismiss code as unreadable because of indentation or naming conventions. Many programmers arrive at some style or paradigm for development that works for them -- a local maxima -- then judge everyone else according to their metrics. Farley's podcast dealt with Extreme Programming, and he relentlessly promotes CI/CD. If you don't do XP, CI/CD, OOP, functional, "Clean Code," take your pick, your code must lack quality, because you didn't use some version of "best practices."
Brian Kernighan and P.J Plauger wrote The Elements of Programming Style [2] back in 1974. That book summarized many of the heuristics experienced programmers had come to use for writing quality code, and judging the quality of code. Kernighan focused on writing code, not so much on system design or how to organize projects, but I think he did put his finger on a lot of what we think we mean when we talk about code quality. Kernighan also gave the nicest and clearest illustration of code readability, or quality, as a skills issue in The C Programming Language (2nd Edition) in chapter 5.5, when he walks through multiple implementations of `strcpy` from beginner to expert, while explaining pointers.
I listened to the podcast and couldn't tell what Farley meant when he referred to "more traditional approaches," but in context it seems he means any development style other than XP and/or CI/CD/TDD. I think saying that those "traditional approaches... start off assuming that we have get things right at the beginning" caricatures up-front planning and design, drawing a false dichotomy between so-called waterfall (traditional, I suppose) and agile and XP. Farley looks old enough to know better. Software development embraced the reality of software changing over time, and new requirements driving ongoing development and maintenance, way back before I started programming over 40 years ago. The concepts of modules, cohesion, and coupling -- central to designing and implementing readable and maintainable software -- got described back in the 1960s by Larry Constantine [3] at the beginning of the structured design phase of the industry trying to grapple with large-scale software development and maintenance lifecycles.
No serious software designer ever started out assuming they had to, or could, get everything right at the beginning. Waterfall never worked that way either, it always had feedback and iterations, formal or informal, and programmers understood the necessity of iterating and checking in with users and stakeholders back in the olden days. Maybe Farley meant to contrast with some other tradition that I don't know about.
[1] https://daedtech.com/how-developers-stop-learning-rise-of-th...
[2] https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...
[3] https://en.wikipedia.org/wiki/Coupling_(computer_programming...*