The joke is that there are two hard problems in Computer Science, and the one that I find myself trying to solve far too often is the problem of Naming Things. If you really want to know the other (or others, depending on how clever you are) you’ll have to keep reading (or hop over to Google quick, here’s a link: “naming things”). In the meantime, let’s focus on how to completely side-step this issue so we can get on with our day.
I love software architecture. I get great joy in collaborating with our talented engineers and teams, designing a solution, and working through the ups and downs of implementation and delivery. But one thing that never fails to happen is when a great design conversation is happening and someone stops and points out “I think we’ve figured out this concept, but what do we name it?” And then everything is derailed and you can be sure that the rest of the meeting will have one purpose: figuring out what to call the stupid thing. I have literally attended hour long meetings where the only agenda item was “Come up with a name for this thing”.
Now, to be clear, I’m not talking about the annoying problem of being in the flow while coding and getting hung up on what to call a parameter to a function so other developers will know what you’re talking about. And I’m also not talking about when you get to the stage of delivery where you truly need to have a name that will help to communicate what the thing is for. But, rather, what do you call a thing (concept, new API or service, algorithm, design, whatever) when you’ve first recognized that the thing is a Thing. And that brings me to my first point.
When is a “thing” Actually a “Thing”?
Computer Science, and by some extension Software Engineering, is all about solving problems by adding another layer of indirection. Look it up, I believe it is credited to David Wheeler (Layer of Indirection). And one of the most rewarding experiences is the moment when you realize that a new layer of indirection is exactly the medicine to cure the ill of understanding a problem. That moment, however, is fleeting when you realize that that layer… it needs a name. As professional software developers, we have all kinds of go-to names in our shared repository. (Is it a Service? A Manager? An Engine? An API? All of them?) But, can we agree on one? Or, is the favored name already being used? The answers, inevitably, are “No” and “Yes”. Every… dang… time.
Pseudo-Lean Principle: Deferred Naming
One of my favorite principles of Lean is the practice of Deferred Commitment. Deferred Commitment means waiting until the last feasible moment to commit to a decision. This exact practice can be applied to naming things. And the way I like to use it, as we start down the naming rabbit hole, is to ask myself how truly and critically important it is that we know the exact name of a thing at this exact moment. Often times it really isn’t important. What is important is the shared understanding of the concept or responsibilities of a system. If in a discussion the team feels good on that, we’re good. We don’t have to have that debate right now.
Unfortunately, you will have to decide on a name at some point. It could be when the inevitable refactor will start to become too costly, or people start asking questions about how progress is coming on “the thing”. The beauty is that you’ve had some more time to step back and view “the thing”. Maybe work with it and make it a bit more concrete. There does tend to be a debate about the name at that point, but it is a more informed debate. And if you can wait long enough it can be a really informed debate.
That’s not the end of this tale, though. Because in the interim it is still important to at least call “the thing” something (and hopefully not “the thing”). The reason is that an abstract concept like another layer of indirection is going to remain abstract until you start really thinking of it as something with a name. Names are very powerful. And as long as you can let go of an initial, uncommitted name, I have a method that might be helpful. And it starts with a story about a dark and stormy night.
A Story of Not Naming
A team I work with has gotten really good at deferring the official name of a new concept. We simply take the initials “PM” and stick on to the first letter of whatever seems like the closest description of “the thing” at the time. PM, in context, doesn’t really mean anything, except maybe “apply a name here later”. It started with one of the engineers on the team who would use the phrase “Purple Monkey Dishwasher” anywhere that a company name or item description was needed, but the actual name didn’t really matter. The phrase itself has an interesting origin that is worth looking into (when you’re done reading this, of course).
We came up with our naming solution when we were designing a new system, and we needed to come up with a name for the API. We had a firm understanding of what the API’s responsibilities would be. We were excited to get going on developing it. But we couldn’t write a lick of code until we knew what the name of the repo and the API endpoints would be. We went back and forth for way too long. And we were under a deadline to get some exploration and concepts proven out. And, of course, the then obvious choices for names were already being used by somewhat different applications. That is when the moment of inspiration hit. We knew what we were talking about, we didn’t need THE name, we just needed A name. And, so, we reached for inspiration from what was essentially a team meme and chose the abbreviation for “Purple Monkey Dishwasher”, PMD, as the name of the API. All pressure was off. We completely deferred committing to a name and were able to start making progress again.
We eventually came up with a name, and we’re still very bought in to it. But the PMD name had an interesting side-effect. Because we were doing many new things we kept running into situations where we had new concepts whose obvious name was something that already existed. Typically, almost without delay, we would slap a “PM” on to the front of it and move on. It was an incredibly liberating approach to naming. Some of the PM-names have even stuck (though they’ll get replaced eventually). But the progress the team has been able to make by recognizing those situations where there is a new concept, building a shared understanding of what it is, and then giving a random name to it has allowed for so much more fluidity to the design process.
Find Your Not-Naming-It Name
To tie it all together, when you find that perfect layer of indirection, and you start getting stuck on what to call it, exercise the practice of deferred commitment and just apply some name. It just isn’t that important to get hung up on right now. And so, I’ll leave you with a wish that you too can find your Purple Monkey Dishwasher and solve all your frustrating naming problems.
P.S. Cache Invalidation, that’s the other hard problem. And, if you forgot that I’d answer the question at the end of this, then maybe the solution is really as simple as reading the post! All hard problems can be solved with another layer of indirection, after all.
