Yes, I know I missed the peak on renaming software terms, like changing the default trunk branch name from “master” to “main,” or the trend of renaming “whitelist” and “blacklist” to “allowlist” and “blocklist,” but I’m also not trying to change how I talk because people are capable of stretching words until they get offended. That’s always going to be an issue, and I don’t have nearly enough patience to indulge it. What I am trying to do is avoid terms that have developed connotations that lead to bad programming habits, and replace them with ones that are clearer about what I’m trying to accomplish, and don’t invite people into fixating on the wrong pieces and losing sight of the point.
“Microservices” (and “microservice architecture”) -> “Services” (and “service-oriented architecture”) – I made an effort to drop the “micro” from “microservices” a few years ago. The “micro” prefix encourages people to try to run up their deployed service count like it’s the score in Pac-Man, instead of building well-scoped, self-contained software that covers the problem domain at hand. Sometimes that’s small, sometimes it’s bigger, but “microservices” discourages even considering the latter option. Artificial requirements don’t help solve problems, they make what you’re having to support needlessly complicated. Architecting and designing for resiliency and horizontal scaling is hard enough, but arbitrarily breaking a service up for that (not nearly as magical as you think it is) 5-letter prefix just creates a set of dependencies that’s worse than just packaging up more code.
“Readability” -> “Understandability” – “Readability” certainly rolls off the tongue more easily than “understandibility,” but the latter is what we actually mean. The problem I’ve seen is that people assume “readability” means “less characters in the IDE.” That’s not what “readability” means. “Readable” code is code that someone can read the code and then immediately understand what it does and start working in it. The problem with focusing on “less characters in the IDE” is that it encourages super compact and overly clever code, instead of simpler, explicit code that describes exactly what you’re trying to do. Here’s a quick thought experiment to help illustrate my point: according to Amazon, the first Harry Potter novel has 320 pages. By contrast, Einstein’s book on relativity has 176 pages, making it 55% the length of Harry Potter. Which one do you think would be easier to read? Odds are you’d say it’s the young adult novel, because length has very little to do with how easy it is to read something. Personally, I’d rather take the time and effort to write software that people can skim, understand what it’s doing, and immediately debug if needed, and the term “understandablility” helps remind me of the point behind how I’m structuring and writing code.
“Unit testing” -> “automated testing” – Testing software is great. Having those tests run automatically during the build pipeline is really great. Being able to fire off all of those tests locally before sending that code to a server is wonderful. But “unit testing” encourages people to fixate on units, Specifically, it makes them focus on individual functions as units. The problem with emphasizing “units” is that you encourage yourself to miss the forest for the trees. If I have to stub nearly everything to ensure only 1 specific function is being tested, and as a result can’t get (or query) the final application state after performing any action, I just have a bunch of brittle code that I’m burning hours on to pass a build pipeline’s test coverage check. Switching from “unit” to “automated” is a subtle reminder that tests can be scoped to actions and workflows, not just methods, and still effectively run automatically on every build.
I’m sure there are other terms that are doing little more than encouraging bad behavior and overcomplication, but these are the ones that I’m focusing on right now. As a profession, we’ve gone abstraction-crazy and are all too happy to outsource thinking and engineering to glorified autocomplete. Good engineering simplifies, and I can remind myself of that fact every time I talk about what I’m doing.