Don't write SharePoint Timer jobs (etc) without good reason

Here's some sample Q&A from a forum thread I was involved with recently. Some of the text has been changed to protect the not so innocent;

Q "I have a Document library which will store some accounting files. Each of the files have a validity start date and a validity end date. Is there any way to send out an email automatically 2 weeks before an individual file expires?"

A "You should write a timer job which runs weekly checks the items expiry date and sends out an email"

There seems to be a bit of a trend on the SharePoint forums these days to recommend bad solutions as good SharePoint wisdom. Perhaps it's always been so, and I was too starry eyed to notice. :)


My bugbear is suggestions that custom development be used for everything.

For example I've seen several examples recently where someone has asked how to implement behaviour in SharePoint that has some sort of delay or repetition in it. I've been prompted to write about this because the answer that keeps cropping up is "write a SharePoint Timer job to do it".

SharePoint Timer jobs are a powerful weapon in the SharePoint Developer arsenal. They offer the potential of regular batch processing, perhaps outside of regular business hours with full access to the features of the SharePoint API and beyond. Though you should consider the alternative here

So any processing that has a batch or delayed element to processing should use a timer job right? ... No, no, no! Timer Jobs are not the answer to all such problems.

Using a Timer Job as your solution needs careful thought. A badly written timer job will compromise SharePoint performance. A heap of timer jobs written to address every

need that came along will stop the farm operating, and make upgrade more than a tad difficult.

Here are my problems with this;

1. Custom Development resource is available to a minority of the questioners in my experience

2. Bad custom development can be a major blocker to upgrade and migration and should be limited to when it is needed.

3. SPD Workflows can often achieve the actions that are being asked about, which makes custom timer jobs look like a sledgehammer to crack a nut (or any other custom dev for that matter).

4. Developing timer jobs whenever a requirement needs to be met will soon result in hundreds of the things potentially running at once and chewing your server resources so that nothing works anymore.

5. It's very clear that the current wind is trying to blow us all onto the shores of cloud solutions. Custom server side development will not be allowed in this brave new world so be cautious about server side development of any kind.

It's really cool that people get involving in the forums to answer the questions of others. There are issues I personally wouldn't have solved if someone hadn't answered a question or blogged about it - the SharePoint community contributions ease a lot of pain in the workplace and have probably saved the world zillions of dollars. I would ask though for a little care about what solutions and advice are offered.

If you have a hammer, every problem looks like a nail. If you're a SharePoint Techy, every problem might look like a custom coded solution, a timer job, a web part, an event receiver. However there's an awful lot that can be done via the UI or using SharePoint Designer or Infopath. Most of the folks who've implemented SharePoint don't have a Development team available to them, or even if they have they might have an arduous procedure to actually request the team work on something. Let's have a little mercy on the SharePoint user and spare an extra two minutes thought to suggest no code solutions within reach of the majority of users.

Now I have to climb down from my soapbox without taking a tumble...

Happy SharePointing!