April 2008 Archives

The latest post at Rands in Response started a bit of a heated discussion with a group of friends, and I thought I'd touch on a few of the reasons I think it is absolutely imperative to automate, even if the automation only saves a second.

The concept of automation is an old one. In fact, automation is the reason computers were built in the first place. They were used to automate processes that were too complex or laborious for humans to tackle themselves. In early days, these complex tasks were simple by today's standards; "discover the trajectory of a bomb" or "calculate one plus two". However, as computers have become cheaper they've started to automate everyday things. This is painfully obvious to anyone who lives in the 21st century, but it's a fact that programmers shouldn't forget. A good programmer is someone who's always looking for redundant tasks that can be automated; both to save time and to reduce human error.

Saving time, however, is a concept that carries with it many externalities. The day of writing this post, I have been working on a fairly complex shell script with many moving parts. This itself is not a problem, but the fact that I've been asked to respond to a few emails at random times during the morning provides a significant complication. As "sufferers" of N.A.D.D. will understand, taking 60 seconds to send off an email may well torpedo 30 minutes' worth of productivity. Extrapolate that to 3 separate yet short tasks, and I've lost about half of my morning. This is an important measure to bring into the cost/benefit ratio when discussing automation. Typically, the equation used to calculate a processes' automated value is the following:

a = Amount of time for task (un-automated)
    * Number of times task performed
b = Amount of time for task (automated)
    * Number of times task performed
    + Amount of time to automate the task

If b is less than a, then the task should be automated.

However, this simplistic equation misses the issue entirely. If my automated task is short enough to keep me from getting sidetracked by any of the hundreds of windows on my desktop, then it's paid for itself after two uses.

I was one of the lucky few to get an account in the first round of AppEngine signups, and today I started in on my first app.

I recently found Edward O'Connor's backpackit entry on Personal Unit Tests, and I thought this would make a great little app to get started with. It's like a daily goals tracker, but with a very slightly different focus. More on that tomorrow.

Overall, I was very impressed with the amount of minor annoyances google has removed with this new setup. Having worked with these types of webapps for a number of years now, I know that they're rarely easy to host and deploy, but google has certainly taken the grunt work out of the equation.

I was most impressed on the user account tie-in they've built. It's absolutely trivial to let people use their own google accounts [gmail accounts] instead of creating a new account on each site. Effectively, they've built their own OpenID implementation into the framework.

At the end of the day, I'm reminded a bit of GeoCities and Tripod, who brought static webpages to the unwashed masses. With AppEngine, all that's needed for a small app is a handful of yaml, some html, and a few hundred lines of python.