Pragmatic Prose

Design Validation - Or Why Windows Task Scheduler Rules

At one point in time it was thought that writing a Windows Service (then an arduous task b/c it required C++) was the ultimate solution for automated business processing.  However, the state of practice involved a VB application running in the Windows Task Scheduler.

However hokey it may have seemed, the Windows Task Scheduler (like *nix's crontab) is the most robust way to run processes on a scheduler. 

Here's some validation from Jon Galloway:

http://weblogs.asp.net/jgalloway/archive/2005/10/24/428303.aspx

A Windows Service is the wrong solution to scheduling one-off custom processes. The right solution for scheduling simple processes is the Windows Task Scheduler.

Scheduled tasks are awesome and server most business process purposes just fine.  Reporting could be better and Windows Vista takes the task scheduler to a whole new realm of bizarre complication, but all in all, it's not bad.

Now, why do all the "smart" engineers at Apple, Google, Sun, etc, decide to design their own "always on" services to run either all the time or to start at boot time?  Don't they know about the Windows Task Scheduler?

I'm sure they do.  I'm guessing at some meeting some project manager looked at the way Sun has done their Java updater for the longest time and thought this was right.  After all, the user could turn off the task scheduler service and we NEED to make sure that Java/Picasa/Chrome/iTunes is updated every day/week/month/year.

In the end, the simpler solution is usually the best one.  Windows task scheduler has worked well for me for years. 

I've played around with Windows Service projects in .NET but thankfully, I've never actually had to put one in production.  There are so many simpler (and arguably) better solutions.