The day that only had 23 hours

Earlier this morning, our clocks sprung forward an hour. One minute it was 1:59, and the next, it was 3:00.

It’s common in web development to run maintenance tasks in the early morning, when server traffic is at a minimum. If you have a task that runs every day at 2:15 a.m., it didn’t run today. If you have a task that runs every hour, today it only ran twenty-three times.

I suppose we’ll make up for it on November 3, the day with twenty-five hours, where a 1:15 a.m. job runs twice.

Of course, this assumes your clock is set to a timezone that participates in Daylight Saving Time (not “Savings”). Imagine two servers operating ten miles apart: one in Indiana, one in Illinois<span font-size: 80%>*</span>. Today, if both were set to local time, one had a twenty-four hour day, the other twenty-three. One minute the clocks were in sync, the next they were an hour apart.

This is one reason why building software often takes longer and costs more than expected. Not specifically because of timezones: DST issues are predictable, and there are a number of best practices to avoid them.

It’s because there are _always _gotchas. If there are exceptions to “facts” like “There are 24 hours in a day,” imagine how many exceptions there are to the rules that govern the web application you dreamed up three months ago. Assumptions like:

• A user will never need to change their email address.
• A product will never be assigned to more than one category.
• Everyone will have a unique social security number. (One of my favorite gotchas comes from the California Department of Education, where they have over two hundred kids without an SSN named “Juan Garcia.”)

There are exceptions to almost every assumption, and they often aren’t apparent until you start writing code, or until you put the product in front of the customer. Seemingly simple problems tend to become more complex the longer we look at them.

This is why, at Table XI, we don’t sign fixed bid contracts, and don’t reply to RFPs. It’s why we start our projects with a thorough inception process where we ask “Why?” more than an annoying toddler, and why we use Agile development to juke-and-jive as requirements change.

And it’s why we’re skeptical whenever someone says, “I already have the wireframes, I just need you to code it”, because if we asked that same person how many hours are in a day, they’d swear the answer is twenty-four.

<span font-size: 80%>*As Howard pointed out in the comments, all of Indiana now recognizes DST since 2006 (coincidentally, the year after I moved to Chicago). Sub in Arizona and California for the illustration to work.</span>

I originally wrote this back in November, but it’s such a fun point, I couldn’t help but bring it back.