The Mistake I Made When Trying to Name a Non-Existent Thing

Developers must possess the crucial skill of naming things. Oftentimes, I found myself stuck in a problem until I came across the right name which directly led to a solution. Usually, the root cause of the issue is treating two things as one. Once these things are distinguished, each can serve their respective functions, and the solution will follow.

While naming things is valuable, not naming a non-existent thing can be even more valuable.

The Origin Story

Our story starts out simple. You’re making a project management system and you have a new thing in your system, lets call one of these things a Project. It has some basic data: name, due date, a reference to a client etc.

One day, you decide to be able to delete a project. Simple enough, just remove the row from the database. We are following along with standard Rails conventions so that just means sending a delete request to the destroy action on the ProjectsController. Perfect, we can close that ticket and keep working on that new ChatGPT module.

Time goes on and the obvious next feature request comes in. They need to un-delete projects… Well there is no undelete REST action so I guess I need to come up with a name for a nested resource that represents deleting and undeleting. This is where I made a mistake.

The Struggle

My first reaction was to extract the idea of a thing which represents the deleting and undeleting of a project. Now clearly calling this a “delete” doesn’t makes sense because if it was deleted it’s gone and cannot be undeleted. So the name of the thing would have to be something like an archive. But if I create an archive a project, the original is still around right. So does that mean the button for this action should say something like “Archive and Delete”? That seems…wrong.

This exact same problem has come up and every time I try to come up with the right name for the thing, and it has eluded me every. single. time.

Until now

The Solve

The solution to this problem is painfully obvious once you can see it. The entire problem is coming up with the right name for a thing, and the reason it’s so hard is cause it isn’t a thing.

That’s right, it can’t be named cause it isn’t.

Now down get me wrong, I’m saying this specific thing, isn’t a thing. Looking at what Basecamp does with incineration, that’s a thing. If this had more to it than just toggling a boolean value, it also might be a thing. But it isn’t.

This isn’t a thing, it’s just posting an update to a single field. This is literally just a <%= button_to 'Archive', project, params: { archived: true } %>.

The Takeaway

I was making a small thing into a bigger complicated thing. Because I was looking for extra complexity, my solutions always felt wrong.

When you are creating software, it’s easy to fall into a mode where you are “building beautiful code”, but not the code you need. This leads to code that often doesn’t fit the real problem you are trying to actually solve.

If this delete/undelete feature grows into something more robust, like Basecamps incineration concept, then the names I give it today will likely be wrong. This means I’ll have put in a bunch of effect upfront coming up with the wrong structure, with the “upside” of undoing all that work to build the right thing later.

Name things, and name them well. But don’t forget to use other tools too.