Developer Timesink: Name Paralysis
I’ve recently become aware of a phenomenon that really hurts the productivity of software development teams when it arises. Once I recognized it, I began to realize how frequently it actually occurred. It was when I heard other people describing their workplace that I realized that this might be an omnipresent programmer hurdle. The most interesting part (and the reason for this post) was the simple act of recognition solved the problem. Here’s a simple example of how it might happen:
You and your team sit around and decide you really need to wrap up some set of (messy) functionality into a nice clean interface. This new module can replace a half a dozen semi-hacks that are used in different places and will provide a ton of flexibility. Sounds like a great idea. After a bit of discussion about the requirements of this module, you go sit down but you can’t start working. Why? Because in order to create that new header file (or module or package or whatever) you need to know what to name it. Everyone is going to be using this thing, you think. Seems like a big decision. Maybe you need to take a moment to figure that out. You get into a tiny argument with yourself. All your naming ideas stink. Hmmm…
I called it name paralysis.
Name paralysis happens when you get stuck on a naming issue and nothing is done until the name crisis is solved. And it happens at every level. I’ve known people who can’t write a line of code for some new application until they figure out what the name, logo, and icon should be. Same for web pages. Same for entire websites. Hell, even the same for entire companies. There are people who cannot do any work on their start-up idea because they need a name and a logo first. I’m not an expert but that’s definitely not healthy. And it goes down to header files or modules. Even individual functions.
Most cases go away quickly because some self-evidently perfect name bubbles to the top. But sometimes it doesn’t. Sometimes your cube neighbor can solve the problem for you. Sometimes, though, someone overhears this conversation with said cube-neighbor, and now there are three. God forbid, however, that this conversation happens inside a meeting.
Name paralysis’ effect on time-wasting is geometric with the number of people. It can get absurd. Ever tried to come up with the main website tabs in a group of 10? If you can agree on that inside of 30 minutes, congratulations. People will sit around and discuss the pros and cons of what are essentially synonyms for dozens of minutes. It’s just human nature. I don’t know why, but it’s unavoidable. The issue isn’t that the names don’t matter. Names matter. They just don’t matter yet. We haven’t written a lick of code and we have 10 people arguing over something that can be changed with sed in all of 45 seconds.
Solution #1: Make a Decision
Don’t be afraid of making a name that people will want to change. It’s better than the alternative. If you paralyze everyone for 30 minutes to come up with a good name, you’ll start a big argument and probably not get a name everyone likes. If, on the other hand, you just name it something, even if it is awful, people will think about it on their own time and someone will come by at some point and mention a better name. The second scenario is infinitely more efficient.
I once named a package and accompanying source files “image_processing”. That was an awful name. I got so much shit for that name. In our business, that’s the equivalent of naming something “math” or “the_library”. I mean half our code base does image processing. People’s visceral hatred of that name made them motivated to come up with a better name (on their own) and eventually we renamed it to something we came up with (in the course of casual mockery of me and my naming) over lunch.
Another co-worker once had to name a function that took an angle and returned a polygon. The higher the angle, the more pointed we’d want the polygon in some particular direction (you can get an idea from our gallery to see what I mean). He named some internal function “calculate_pointiness”. That’s an awful name. I don’t think he meant it to be permanent. But it ended up being kind of charming and the vocabulary has stuck.
Solution #2: Table It
Once I was aware of the ability of large groups of people to become paralyzed by a naming discussion, I just started interrupting everyone by saying “this is name paralysis” and the problem just went away. We got into an argument about a web page’s section names and I just said “Ok, this is name paralysis” and the conversation moved on. The name seemed descriptive enough that everyone immediately understood what was happening. It was a pointless and premature argument. Let’s talk about something that matters. And everyone seemed to agree. It seemed to me that the very act of naming it and pretending it was some trap we tended to fall into made everyone instantly aware of the time that was being wasted.
Solution #3: Suffer
Sometimes, it has to happen. Names do matter. If it’s late in the game, you don’t have a choice. If your website is about to launch and you still can’t figure out a name for that third tab. It’s time to call a meeting and suffer.
August 27th, 2008 at 1:28 pm
Typo:
You are and your team sit around and decide you really need to wrap up some set of (messy) functionality into a nice clean interface.
s/are//
August 27th, 2008 at 1:44 pm
Sigh, thanks Beany.
So far this blogging thing has taught me that I’m an awful proofreader of my own writing. No matter how times I read through.
August 27th, 2008 at 1:45 pm
Good points about moving on. Once everyone gets ruffled in a meeting there is a tendency to do nothing until everyone agrees. Then it’s important to remember no decision is a really, really bad decision.
http://c2.com/cgi/wiki?AnalysisParalysis
August 27th, 2008 at 2:36 pm
I find when stuck with a name, that trying to name it in the context of a haiku usually helps:
please find the square root
approximation using
the Newton-Raphson
See? Clear and poetic.
August 27th, 2008 at 2:50 pm
My trick for this is that I name it a random senseless string. I gets people asking what it’s for, which gets both you and them thinking of a good name. Also, it’s easier to search and replace in your code base without risking replacing the wrong text, which could happen if the name you chose initially was part of another function name or something like that.
August 27th, 2008 at 5:20 pm
Something similar, when the project is first getting started, is framework paralysis. You know what I’m talking about.
August 27th, 2008 at 5:29 pm
This is excellent advice. It fits nicely within the larger framework of distinguishing between decisions that are easily reversible (like where to place office furniture) and those which are not (like which vendor to choose). Names, of course, are a hybrid—easy to change when a project is in the earlier stages and somewhat harder to change later on.
August 27th, 2008 at 8:53 pm
Absolutely, John.
The big difference though is that frameworks are hard to change later. There is a point where arguing over a framework becomes couter productive for sure, though.
August 27th, 2008 at 11:23 pm
Leo Brodie, the author of “Thinking Forth” (way back when), said that the most important development tool was a good thesaurus to help with picking names. I find naming to be critical, and often overlooked. Thanks for a great article.
August 28th, 2008 at 5:41 am
The ideal would be to rename things as you go, so that names of components would match their individual role in the whole system. As you add more and more code, it would be nice to be able to keep names of classes, variables and functions constantly up to date.
So for example when adding first two components to the system you could just name them “FirstComponent” and “SecondComponent” and not worry about naming consistency in the future.
August 28th, 2008 at 6:50 am
The mathematicians Cartan and Eilenberg once wrote an entire book with gaps wherever a crucial term was to appear, because they couldn’t decide until the very last minute what that term should be. They eventually inserted their chosen term at the galley proofs stage. The important thing to note from your perspective is that their inability to choose a name didn’t stop them from either doing the mathematics or writing the book!
[The name they eventually chose - "exact" - has never seemed all that good to me, but maybe it would make more sense if I knew more homological algebra.]
August 28th, 2008 at 7:04 am
No no no no, you’re doing it wrong! http://sancairodicopenhagen.com/joe/five_tips_to_better_variable_naming_practises
August 28th, 2008 at 10:44 am
Right now, names do matter. Not just later, but now.
Sure, you can change a name in sed. But that’s missing the problem completely.
The problem is when you have an ambiguous name, different team members develop against their own, sometimes mismatching, ideas of what that name represents. Let’s say I name a variable setView.
To Adam, it means set the current view.
To Bosco, it means a set of views.
To Joe, it means a fixed, static view that cannot be changed.
This example is deliberately contrived to make the problem more obvious. In real life, the names are not as glaringly bad, and the differences in interpretation are more subtle, but they are still there.
Then each developer writes code with their own idea in mind. And when Joe looks at Adam’s code, it kind of makes sense, but seems strange, but Joe brushes it off, wanting to worry about his own stuff. The code diverges and pretty soon you have something sed won’t help with.
August 28th, 2008 at 3:05 pm
In my experience, one of the riskiest time for name paralysis is when creating source control repositories for new projects. It’s often very difficult to rename an existing repository (with all the tools I’ve used, at least), so there’s a natural tendency to try to get the name *perfect* the first time. Then you can get stuck before you’ve even started!
September 8th, 2008 at 4:19 pm
Great article. I often get caught by name paralysis, and I can hardly move on, then. Usually, it goes away after a while..