Dave Farley On What Makes High Quality Code
This morning, on the latest episode of the Engineering Room podcast, Dave Farley said something about code quality that really connected with the way in which I see software development. In the past, I've talked about the importance of writing code that's easy to find and easy to delete. But, both of these concepts tactically roll-up in a higher-level strategy that Dave identifies: write code that's safe and easy to change:
The more traditional approaches start off assuming that we have to get things right at the beginning. But we start off assuming that whatever we do is going to be wrong, it seems to me, in profound ways. And so we work in ways that allow us to be wrong safely. And easily correct it when we find it. (57:30)
.... So I've come to the belief that the only definition of quality in code that makes any sense is our ability to change the code. If it's easy to change, it's high quality; if it's hard to change, it's not. (59:30)
This notion that hard-to-change code is low quality code hits me in the gut. This is so much of what I've been wrestling with lately. Every choice that I'm making in my application architecture has, to some extent, been going through this lens: is the choice I'm about to make going to make my life easier or harder?
I'm sure that some people will have the reaction that such an outlook is nothing more than an excuse for not doing things the "right way". But, I think that's exactly what I love about this insight—that it separates out the academia of software development from the pragmatic realities of the world. Sometimes, the sub-optimal way is actually the way that makes the code easiest to work with. And, that's 100% awesome.
Reader Comments
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
strcpyfrom 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)
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →