The DX Files: Improving Drupal Developer Experience

I am declaring a personal crusade to improve Drupal’s “Developer Experience,” which I hereby abbreviate as “DX.”

User experience can be defined as “the overall experience and satisfaction a user has when using a product or system.” A product’s UX affects a user’s interest, ability, and enjoyment when using a product. If a product’s UX sucks, people will not use it if they have a choice or hate using it if they do not.

Well, guess what? Software engineers are people, too. When creating a software product that is intended to be used by other developers, the UX includes the experience of those developers as they write code for the product. But software engineers aren’t exactly like normal people and the kinds of issues developers face are very different from the issues the end users of the product face, so it seems logical to me to talk about DX distinctly from UX just to keep the target audience straight.

My first attempt at a definition for DX is “the overall experience, satisfaction, and efficiency a software developer has when using a software development platform.” I’m sure a better definition is possible.

The Drupal community has not historically been great at UX design (mostly we’re just a bunch of hackers) but recently has focused its enormous talents in this direction and started to make great strides. Somewhat surprisingly, we have also not historically been great at DX design. Drupal is quite powerful and flexible but unless you climb a fairly steep learning curve it can be hard to develop for. I have personally spoken with a number of web developers who have evaluated Drupal and found it too annoying, too unlike everything they have done before, and sometimes just too “backwards” for them to want to use it.

There are many, many ways to improve Drupal’s Developer Experience. Some are trivial, some are complex, and many are in between. My plan is for “The DX Files” to be a series of articles describing what I consider to be poor Drupal DX and suggesting solutions.

Since I’ve already rambled on a bit, I’ll start with a very simple DX issue for today: string literals vs. defined constants. Consider this completely typical example from Drupal’s user.module:

function user_register_access() {
user_is_anonymous() && variable_get('user_regsiter', 1);

This function determines if a particular visitor has permission to register for an account. It says the user must not yet be logged in and that the site-wide “new user accounts are allowed” (user_register) setting is enabled. The variable_get() function takes a default value as its second argument which, in this case, is 1 for “enabled.”

The example uses a string literal ‘user_register’ instead of the much more accepted approach of defined constants. Why would a defined constant be better? All the standard reasons: more readable code, the ability to change the constant in one place instead of many, detection of typos at compile time, auto-completion in IDEs, etc.

Case in point: did you notice that user_regsiter is mis-typed? (Note: I introduced the typo for this example; the real code is correct.) The program still “works” but contains a security flaw: If the administrator sets the “user_register” setting to disabled, this code will not see it because it is looking for “user_regsiter” and as a result will use the default value of “enabled.” Oops.

If the user module used a defined constant, the bug could not occur:

('USER_REGISTER', 'user_register');
user_register_access() {
user_is_anonymous() && variable_get(USER_REGSITER, 1);

Now the code will simply fail to compile and the typo will be discovered immediately.

I actually believe there are two other flaws in user_register_access(), one DX-related and one security-related. Will you be the first to point them out?

UPDATE on May 19, 2008: I’ve submitted at patch to replace all Drupal “variable” names with defined constants; see

To happier coding!