Choosing a name

by Marty Alchin on May 18, 2007 about Django

For those of you who have been following my progress lately on django-developers, that title probably makes some sense. For the rest of you, I’ll explain. I’ve been working on on a project for quite some time now, with the goal of eventually being accepted as a contrib app in the official distribution. Trouble is, nobody (myself included) likes the name as it stands: django-values.

Essentially, it’s an attempt to encourage separation between programmers and managers with regard to certain values that are management-related, rather than technology-related. Since I’m not using standardized terminology (I don’t know if there even is any) I’ll attempt to illustrate the difference by describing a few situations of each.

As you can see, technology values can reasonably be stored directly in code, because they won’t change. They’re dependent on mostly immutable forces like the storage type of a basic text field, the numeric capabilities of a 32-bit processor, or basic rules of time calculation. In order for management to change any of these, they’d have good reason for calling in a programmer, because a lot would have to change in order to implement any changes.

Management values, on the other hand, are those that have no relation to any technical limitations, but instead simply impact the logic followed by the application. These may change considerably more frequently, and with extremely little impact on existing code. Unfortuantely, since they’re used in code, they’re generally stored in code too, so changing them still requires a programmer. In some organizations, this can also mean the application has to go through a round of testing before being deployed to the public. That’s a lot of overhead for something that really doesn’t even have a code impact.

To make a long story short (too late!), I decided to write an app for Django that allows programmers to define placeholders for management values and reference them in Python as if the actual value had been defined explicitly. Then, management can come in and define or redefine those values as they see fit, without requiring any programmer interaction, or even a restart of the application.

As you can see, this isn’t an easy thing to describe, much less slap a name on. There have been a few suggestions so far, but they were all accompanied by a disclaimer, such as “I call them {{ name }}, but that doesn’t really make any more sense than ‘values’.” So I’m appealing to a greater audience, with hopes that somebody out there has a better way to go about this.

Please help me name my app!