Monday, October 29, 2007

Time Keeping and Scheduling Systems

The following is probably old hat. For me, today, it's worth rehashing.

Recently, I've had to work on a rather feature rich scheduling system. This is one of those tasks that always seems trivial the first time you need to do it, but really isn't. In many, many, many cases, the existing frameworks can't bail you out of the details. Sure, plenty of frameworks and libraries do things like timezone conversion and the like; that's helpful (if not required), but not the complete package.

I was working on recurrent schedule generation with a coworker, GR. Whilst working out the scary details of operating in multiple client timezones, being locale sensitive, guaranteeing non-duplicate job execution, he turned to me with a stunning revelation (as he's known to do, often), and said

You know, this is one of those things that has been done a thousand times, correctly, but none of those implementations were ever right.

Obviously, what he meant is that you can't get this right because it's so heavily dependent on the context within one is operating. It depends on desirable locale effects, granularity of event intervals, and similar concerns. In one case, it may not matter if an event fires twice, once a year, during the day light savings time adjustment; task idempotency may be guaranteed, whereas in other cases, this isn't true (like for me). Maybe you have the have luxury of operating within a single timezone (lucky you). All of these things affect the feature set and can really change the game.

All of the solutions I have (personally) encountered for task scheduling miss the mark, in my current case, in one way or another. It's frustrating to have to build something that seems as if it should already exist. Of course, there are internal, business requirements that prevent me from either going into significant detail, or from my open sourcing the result, but trust me when I say this isn't as easy as it sounds. (I say this in hope of staving off the slew of well, why not just use XYZ comments I'm bound to get.)

If all of this means nothing to you, take away only this: sometimes, being forced to reinvent the wheel gives one an amazing appreciation for the work that went into the damn thing.

Many thanks to my ninja-smart coworker, GR, as well as my apologies for my awful paraphrasing of his insightful, comedic wit, and view of the task at hand.


Anonymous said...

well, why not just use Quartz?


E. Sammer said...

Good question. In this case, I wasn't working in Java. I could have done something like write a thin layer to make web service calls to Quartz, but there were other issues around that.

In retrospect, it might have been better to do that, but there wasn't a lot of expertise from the rest of the team with Quartz and it would have meant a fight with upper management. No one like that. :)

Thanks for the comment (and I'm sorry I didn't see it sooner).