GTD = MPG?

Can following David Allen's "Getting Things Done" regimen give you better gas mileage?

Not exactly, but cheeky opening sentences aside, I've noticed that I now fill my tank once every nine days on average-- instead of every seven. (ed. aside: Yes, I'm one of THOSE people who lets his tank go nearly empty before filling up; get over it.) But according to my tripometer, I still get the same miles per gallon as I did before.

So, obviously something in the way I drive has changed.

It's not a conscious thing. I'm not cancelling errands while muttering about the outrageous price of gas. I suspect what's happening is the Getting Things Done (aka GTD, for short) process of capturing what I need to do, as well as the context in where I can do particular tasks, is forcing me to do a better job of getting organized and planning my errands BEFORE I get in the car.

Instead of running a dozen separate errands as they come to mind during the course of a week, I can plan ahead a day or two and combine tasks. For example, I go to the dry cleaners for pickup and drop off, go to the post office to drop off my bills and Netflix returns, hit the restaurant in the same plaza to grab dinner, which also gives me leftovers I can take in for lunch at work the next day, etc. You get the concept. GTD makes you more efficient, so you get more accomplished with less driving.

For me, filling up my gasoline tank less frequently appears to be an ancillary benefit of "Getting Things Done." Is anyone else out there seeing similar results?

Let's [NOT] do the time warp again! Please?!

MTV readies 'Rocky Horror' redux - Entertainment News, Film News, Media - Variety: "MTV is doing the time warp on a remake of 1975 cult classic 'The Rocky Horror Picture Show.'"

Since MTV and Fox Television seem hell bent on "tampering with things with which man was not meant to tamper," I throw down the following unthinkable challenge.

If you had to cast The Rocky Horror Picture Show today, who would you cast for which part(s)? Be as creative, wacky or outrageous as you want-- you're the producer. Put your dream cast in the comments.

I, for example, would take "Eddie" (originally played by Meatloaf), swap the gender (a la Battlestar Galactica), and then cast troubled chanteuse Amy Winehouse as "Edie."

New Profile Pic

This evening I realized my stylized B&W profile pic was almost 7 [mirabile dictu!] years old. It seems impossible, because the circumstances behind it are still so vivid in my mind-- but it was taken November 2001, at the start of my trip to and adventure in Montreal.

I've decided to update the profile image with a newer, more inviting one. I'm tempted to make reference to the change seen in old and new Peter Gabriel album covers, but I doubt anyone'd catch the reference. Like it? Hate it? Speak your mind in the comments, folks-- that is what they're there for!

Unobtrusive Javascript and . . . a paper towel dispenser???

I've got two ideas for a blog entry, and can't decide which one to write first: the paper towel dispenser story, or the unobtrusive Javascript example. Oddly, the more I think about them, the more interconnected they seem. So, let me take a preliminary stab at this.

Think about a paper towel dispenser in a public restroom for a moment. We wash our hands, pull out a paper towel, dry our hands and throw away the paper towel without much thought. The only time we even think about the people who fill the paper towel dispenser is when they fail to get refilled, right?

I want you to imagine this guy-- his name is Dan. Dan works at an establishment with a public restroom, and part of his job duties is to make sure that the paper towel dispenser never runs out of paper towels. Dan has other job duties though; he can't just sit in the bathroom and watch the paper towel dispenser. So, first thing every morning, he stuffs the dispenser with as many tightly stacked paper towels as he can. His reasoning, of course, being that it will take more time for people to work their way through a bigger/more numerous pile of paper towels than a small/less numerous pile-- which also means he won't have to check it and refill it as often.

Less work for Dan means it's better, right?

That is, until you discover the paper towels are so tightly stuffed into the dispenser that patrons are finding it difficult to get them out. They grab the first one, but it doesn't pull free, gets wet and then tears apart in their hands. So, customers wind up pulling out a second paper towel to dry their hands with a whole piece instead of the torn fragments. Now every customer is using two paper towels instead of one.

You don't want to stuff the paper towel dispenser with as many paper towels as human possible. You want to make sure it never runs out, but you also want to make sure it allows people to easily remove a paper towel when their fingers are wet.

So, where does the unobtrusive Javascript come in, you're wondering? (That makes two of us.)

Web developers need to put Javascript into their web sites in much the same way that the paper towels need to inserted into the towel dispenser. Keep it "loose" and make it superfluous. When people can't get around your site and make use of its core functionality with their Javascript turned off, you've tried to cram too much Javascript code in there.

Training, Testing and Production

The prevailing school of thought (at least where I've worked) has been to keep your trained and untrained users as separated as possible. Don't get me wrong-- if you have deep pockets, and can get separate servers for production, training and testing environments, then by all means go for it.

But the truth is that once people have shelled out money for the database and web servers on the production side of the fence, they start looking for ways to cut expenses. This usually happens by the time they get round to setting up the training server. "Well, can't we just use one server for both the training server AND the testing server?"

This is a really bad idea, for many reasons. A training server needs to be able to handle a set number of users simultaneously (30, 60, etc.), while a testing/development server can get by with handling a much smaller number of simultaneous users. This translates into a horrible training experience for your newest end users/customers-- horrendously long login times, slow updates between pages, etc. The first impression your new users get of your killer web app is in the training, and you're showing them a slow moving piece of turd, ok?

Then, as if that weren't bad enough, developers are always working on the test/development server-- trying to add the new functionality that they've received back from program analysts/customer feedback. If you're lucky, all the new code works great the first time and there are no bugs-- but we all know how unrealistic that is. New code means new bugs, until you take measured steps to locate and remove them. So now, in addition to showing your newest end users a slow application, you're also showing them new, untested code that might or might not have bugs in it.

What exactly do you have against your new, untrained users anyway? ;)

Last, even if there aren't any bugs in the code (lucky you!), the addition of new features typically means that there are new buttons and gadgets in the interface-- so what your end users are being exposed to in their training session isn't identical is look and feel, or even in operation, to what they will actually have to work with in the production environment.

And you wonder why none of your end users likes the whole web development process?

My thoughts on dating

(warning: cynical rant coming up!)

This is simple-- I don't date. Period. I don't need to explain or justify it to anyone. Consider it a lifestyle choice on my part and move on. I don't ask you to defend your (being gay or lesbian/being hetero/being married and monogamous/being an unfaitful two-timer/being whatever you happen to be "into"), so please return me the same courtesy. Live and let live, a'ight?

So, to recap:

1. No, I don't want to date you.
2. No, I don't want to date your sister.
3. No, I really have no interest in your gay friend and/or brother, either.
4. I'm not interested in one night flings, either. Been there, done that, waste of time.
   

I don't need anyone to "fix me up" because, surprise surprise surprise Gomer Pyle, I'm not "broken."

But, wait-- because here's the ironic part: a decade ago, when I wanted to settle down for long term committed relationship, nobody I was involved with was interested. A decade later and three failed relationships wiser, and suddenly I'm Richard F*ING Gere? Let's examine what's changed about me in the past ten years: I've gained weight, my bald spot has grown, more grey hair, lost muscle mass, etc. Nope, no obvious physical gains in attractiveness. Oh, wait, I almost forgot-- I have a house, a car that's paid off and a steady job.

I've done the math on the whole "long term relationship" deal from my past experiences, and found the pluses were less than the minuses. So, do not waste my time unless you bring something ABSOLUTELY AMAZING to the equation.

Chinese Zodiac Desktop Wallpapers

I've been fascinated by the Chinese zodiac for months, so I decided to make a series of desktop wall papers on that theme. They are 1024 x 768, with the characters rendered in the Kai font style, and lots of open space. There's no watermark, branding or URL on them because I think that would have ruined their simplicity. (I use these as the screen saver on my iBook, and they look great with the slow zoom/fade transitions.)

I'm making them available as "Creative Commons: Attribution/Non-commercial/Share-alike 3.0 United States."

Chinese Zodiac Desktop Wallpapers

Whither Twitter?

I've removed my Twitters from my blog, but left the link for my Twitter page available.

Part of the reason was technical-- Twitter's popularity sometimes exceeds its ability to display information in a timely manner, and if it causes my page to load too slowly, I have to jettison it.

Another reason might be construed as more of a "marketing strategy." In Twitter, the number of people "following" your twitter feed says something about how popular/significant your twitter feed is-- it's a "social networking" thing. By displaying all my twitters on my blog where anyone could see it, there was never any reason for anyone to sign up for Twitter to "follow" me. (cf. Free Milk and a Cow) So, if someone really wants to see what I'm twittering about, they can do so through the "Twitter feed" link, sign up for a Twitter account and "follow" me.

The final reason is personal-- I like having some idea of who is following me and the *possibility* of controlling who reads my twitters. At the moment, it's wide open because I generally prefer to be that way. Unfortunately, in the past I've had to deal with a stalking ex-girlfriend and griefers-- if that should happen again, I'd like to be able to click a button and make sure that only people I choose can see what I express in my 140 character outbursts.

Web Development: How it REALLY happens

I have a love/hate relationship with web development books. Don't get me wrong-- some of them are well-written, filled with amazing advice and insights on how web development *should* be done. And yet, few of them, if any, bother to talk about how web development is actually done presently in the chaotic work place.

Here's how it works: the "web guy" in the office gets a visit from a middle-manager (who is not usually his supervisor, I might add) who wants to ask a few questions about a new web app they are considering. It's kind of a rush-job, so "we don't have time for any of that formalized process nonsense, like gathering requirements, so how about if I just tell you what the app needs to do and you just build it for me?"

You could try to explain the value of the requirements and planning phases, except you know from previous experience that managers don't know about technology, they don't know about software development processes. They also don't want to know-- it's not on their radar, and they don't see it as having any value in securing what they do want, so they aren't willing to invest time in learning it.

So, you pull out a notepad and interview the middle manager on "what the app needs to do", and as you take notes, you are also frantically drawing screen mockups/illustrations to try to elicit better quality feedback from the middle manager. It's a fairly small application, with automatic email capabilities, doesn't require log-in authentication, needs to log transactions in a database. You estimate that you can do it with six pages in ColdFusion.

In these kinds of situations, where I'm dealing with the "middle manager/bypassing the formalized process" scenario I have a rule of thumb to estimate how long it will take me to complete the application. I call it the "page a day" rule of thumb. If the application has six pages in it, it will take me six days. If it has four pages, it will take four days.

That's when the middle manager wants to argue/debate the time estimate with you. "Well, you can combine three of the pages into one, so it should only take you four days tops!" Before you think this middle manager (who hasn't done any web development coding since before Firefox was first released) is completely insane, let me tell you the part he hasn't shared with you yet. Prior to meeting with you, this middle manager was in a meeting with his supervisor, and he's just been saddled with an additional requirement out of the blue because someone above him failed to plan appropriately. To make matters worse, he's got no resources to spare and even less time, so he's hoping that you can somehow magically automate most or all of this new responsibility-- because that's ultimately what all technology is about, right, automation? And if you could make that happen before next week's meeting, that would be really super because then he can tell his supervisor that it's all been handled and it will make him look good.

Here are the take aways:

1) For ColdFusion at least, I find the page a day estimate works pretty well.

2) Avoid working for companies where managers think they have the authority to delegate to people who don't even report to them.

3) Managers of web developers should have at least some first hand, recent experience in web development themselves.