Dave Farley On What Makes High Quality Code

100% agree with this. Thanks for sharing Ben.

I will state my conclusion first. Quality in code serves as a euphemism for skills issue. When we encounter code that we find hard to read or change, we might call the code unreadable or low-quality, but we actually mean "The programmers who wrote this code did a poor job," or "I don't have the skills needed to understand this code." If we don't recognize the problem as our own lack of skills we blame the code. Whichever framing applies, putting the blame on the code rather than the author or the reader prevents hurt feelings and bruised egos.

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-the-expert-beginner/

[2] https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style

[3] https://en.wikipedia.org/wiki/Coupling_(computer_programming)

@Ben Nadel,

Thank you for posting the original article and your reply. I agree that George Carlin hit it on the head. I can't count how many times I've heard programmers call someone else's code crap or cryptic; they alone occupy the sane middle ground.

You don't have to spend much time with programmers, in person or online, to hear them throw around words like "quality," "readable," "maintainable," "clean code," "best practice," "productive," "optimal," etc. But when pressed you won't get a good definition or a metric. Maybe they repeat something they read, a rule like DRY or technique like dependency injection that makes sense in some contexts. The software business falls prey to fad, fashion, and cargo cults more than we like to admit.

Of course Knuth got it right too, but what counts as human readable for Knuth would baffle a lot of junior programmers. I have actually read criticisms of Knuth's books complaining that he made up an assembly language for his examples -- why can't he rewrite with examples in Python or Javascript?

We would all benefit from remembering the strongly subjective nature of things we casually talk about as objective properties of software -- quality, readability, maintainability. That would let us focus on helping each other level up our skills and arrive at a shared set of heuristics we can teach and learn, rather than criticizing the ephemeral artifacts.

As for stored procedures in SQL... it depends. You find that more in larger enterprise environments for a few good reasons. From my own experience in enterprise-scale logistics, stored procedures give the organization a single place to implement core business logic, which makes more sense if you think about application software developed over many years, by different teams, and in different languages. You don't want ten versions of a function to check for low inventory levels, you want that in one place. DRY applies to business logic, in other words, not just to chunks of code. At this point someone will comment that you can do that in an application layer. Yes, and you see that in enterprise systems as well. Logically equivalent approaches, with performance or cost deciding one way or the other.

Another reason: atomicity. You can implement atomic operations more safely (and usually with a lot less code) in the database. Think about financial transactions that update multiple ledgers -- all of the updates must succeed or fail together.

For programmers who haven't worked in such environments and who (barely) learned SQL with a less capable RDBMS such as MySQL, stored procedures seem clunky, hard to read, hard to manage in version control, and yet another language to learn and remember. If you use Oracle or SQL Server or DB/2 you will find those problems solved, and stored procedures offer a lot of safety, maintainability, and performance. When I see people dismissing stored procedures as a bad practice I can safely bet they come from a Rails or Node.js or PHP/Laravel background, accustomed to ORMs and query builders, the database supporting one application and code base, with MySQL or Postgres acting as a dumb object store. Don't even get me started with so-called NoSQL, which mostly don't even support stored procedures.

Not trying to promote my own site, but I do have a couple of relevant articles. Free, no ads, popups, affiliate links.

What does code readability mean?

Why don't software development methodologies work?

@Ben @Greg,

I very much enjoyed your exchange here! And I'm clearly out of my depths with the wealth of ideas being shared here, but I care very much about code craftsmanship. I hold Ben's code examples in very high regard and find them extremely easy to read/understand. In my opinion, that is a mark of great code. And I totally get that this may be because his mental model agrees in large parts with my own. It's also probably because I frequent this blog and he's played a large role in shaping my coding outlook and style.

I try to write code that is readable, understandable, safe to change, and safe to delete. We all probably do. Sometimes we succeed. Sometimes we fail. I can't tell you how often I've gone back to code I've written in the past and wondered to myself...what was I thinking? It's easy to not see the trees for the forest when you're mired in the details at the 100ft view, which obscures your ability to make the "more reasonable" trade off from the 50k ft view.

@Ben Nadel, @Chris,

After 40+ years writing code I still look at stuff I wrote and think I could have done better. That just comes with the territory — we learn new and better techniques constantly. No shame in that. It means we have advanced our skills and not got stuck. Over time we experience that less and less. That's what I meant by internalizing heuristics over time.

I spent the day rewriting a lot of error handling code, replacing my own code from a few years ago. And I had the thought, why didn't I do it the "right way" to begin with? Back then I thought I knew the right way but today I have a more robust approach. Still, very likely I will revisit it again in a few years and wonder what I was thinking.