Programmer’s Toolbox Part 3: Consistent Hashing. It would be interesting if something like this could be folded into the currently random slave server selection for HyperDB.
Tag Archives: Programming
Beeping
About five minutes ago, the beeping stopped.
I was in Texas last week for BBQ, clouds, and a wedding. At some point when I was gone, something in my house started beeping. When I arrived home there was a high-pitched chirp about every 45 seconds to a minute, coming from somewhere in the house. Generally when things beep annoyingly it’s one of the UPSes which like to complain loudly after a power outage. The one at my desk and at the closet both had a weird light on back saying “Building Wiring Failure.” (Probably because I removed the ground plug to plug them into a two-socket extension cord.)
I tweaked the UPSes for a good hour or two trying to get them to stop beeping, I pressed the buttons, reset the circuit, unplugged them, left them off, I even flipped my master breaker. (Which reset all of the thermostats to 62, a chilling fact I realized the next day.)
Eventually, I realized the beeping wasn’t coming from a UPS at all, but rather from the smoke detector in my office. I stood on a wheeled chair and sure enough there was a 9-volt battery in there that looked pretty dead, yet it was still wired into the wall in a way I couldn’t disconnect easily. Now that the problem was identified, I just had to find a 9-volt battery (I didn’t have any) and everything would be okay.
That was three days ago. Since then, I came to live with the beep. I found that if I closed the office door and my bedroom door I couldn’t really hear it while sleeping, any more than a cricket chirping. I took calls in my living room instead of my office. Even sitting at my desk, not 5 feet from the smoke detector, I was able to get productive work done with the beeping like a minutely metronome that was hardly noticable. For days.
Engineers do this all the time. We ignore the high-pitched beeping 5 feet away from us that would drive any normal person insane because whatever gene that gives you the programming knack also makes it disturbingly easy to focus and ignore things we’re familiar with.
This is why releases are so important, they force you to clean up your house like you’re having company coming over.
Your assignment today is to take a walk around your blog, application, website, whatever you work with on a daily basis, and allow yourself to be supremely annoyed with the beeping smoke detector in the corner. Let the nagging details of what you do grind like nails on blackboard and amaze you that you have ignored for months or years something so familiar yet so annoying. Obsess about it until you can’t do anything else except fix it, and take the 10 minutes to walk to the store and get a 9-volt battery.
Should We Have Hidden Options?
Alex King has recently suggested that we have an about:config for WordPress. When I first thought this I thought “great!” because we’ve had this for several versions now: if you browse to options.php directly you can edit any option in the database, even those that have no UI because they’re from plugins or just something we don’t expose.
However after several comments pointed this out Alex began clarifying his request, some of it isn’t entirely clear to me (I would never want to go back to storing configuration in files, that was a nightmare we eliminated in 1.0), but the main gist is not merely exposing an interface to the options we have, but rather adding many more options to the code to allow for more than one way for some core parts of WordPress to work.
With that clarification, I think it’s pretty safe to say that something like that will probably never be incorporated.
Options have several costs, which is why we avoid them fairly religiously in WordPress. The most obvious cost is UI clutter — everyone wants their 15 pixels of fame and configuration screens quickly devolve into pages of utterly confusing junk no one understands or cares about.
A very closely related problem is user frustration. With WordPress we’re trying to make publishing to the web as effortless as humanly possible, and one part of this is taking care of a thousand little details that really shouldn’t ever cross your mind — if we’re doing our job right. One common reason for the proliferation of options in open source software is that (news flash) people often disagree about how things should be done, often violently and vocally in threads that can drag on for weeks on development mailing lists. (It is frustrating for many people that these option flame wars draw more discussion than useful topics or questions.) Few like fighting about things, and project leaders pull the proverbial car to the side of the road and declare “Screw it! We’ll do both!” To satisfy a handful of developers a burden is put on countless users.
I try to build everything imagining I have a million users. (Someday!) Small things add up — if there is an option in the interface that people have to think about for only 2 seconds (which is probably low) across a million users that’s 23 days (555 hours) of time lost to the world! (Call centers track efficiency per second because of similar constraints. Small things add up.)
Alex’s hidden options don’t trigger either of these by definition. However there is a third hidden cost: as the number of options increases it becomes difficult (or even impossible) to test for all possible combinations of how the options may interact in different enviroments. This also makes support a real bear. Costs go up, bugs increase.
This is why we say no by default to pretty much every suggested option, and we do our best to remove the ones that have built up over the years. (I just axed a whole panel earlier tonight.)
All that said, hard-core developers often need flexibility in the system to expand WordPress to things we’ve never even imagined, and that’s where our plugin system comes in. While we often say no to new options, we rarely ever shoot down a suggested extension to our plugin API. The beauty of this is it allows for near-infinite flexibility in how you interact with the program (there are some amazing plugins out there) while still keeping the core light, clean, stable, and fast. It also makes support relatively painless: “Does it work when you deactivate the plugin?” When someone says they want to do X and it should be core because it can’t be a plugin, 9 times out of 10 I see that as a plugin API bug, not a core bug.
In summation: Don’t waste your users’ time like I just wasted yours with this essay and be mindful of hidden costs. If I had a few extra hours I would edit and cut most of it out. (Good thing I don’t have a million readers.)