I agree with your point, automation is not always worthwhile, but I doubt your analysis slightly. Does it really take just one minute? And what about the interruption of flow? I have seen estimates between 15 and 30 minutes for the amount of time a developer loses with each interruption. That is the real cost of your manual process.

Don't forget to factor in:

- What is the cost when you forget to do an update?  That one minute assumes perfect timing and execution on your part.  I know you're good, but no one is perfect every time.

- What happens when you're out sick, on vacation, or you win the lottery and leave the company quickly?  Will it be easy for someone else to take over?

Risk is an important variable.

If it takes 1 minute to run and the ROI is 5 years, but it costs $50,000/day if it's wrong, it's absolutely worth it to automate

I tend to think of automation as an executable word document/wiki page. If the manual process needs some kind of description, why not make the description executable?

What about job-satisfaction?

If you let a developer do much of such tasks, you won't have a happy developer and it might be worthwhile to let him automate it?

Tim,

If only looking at the raw numbers, you are correct.  The ROI on this may be years in the future.

But as Chad pointed out.  Humans are error prone, we forget stuff we make mistakes.  If the task can be automated and done simply then do it.  It will remove something from your plate.  It will also remove the 'o-crap I forgot to do X' feeling we get.

Now in your case I would admit that automation may not be the right way to go.  Why, there are too many variables to account for and if any one of those change you will be back at step one, doing it by hand.

Think about your dependencies on this for a minute:

1 - Connect to exchange.  Changing DNS names will kill the app

2 - Scanning for a given email (i assume by title).  If the title changes you will miss the file and be screwed

3 - Scanning the content of the email.  If the layout changes you are screwed

I tend to agree with most of the comments here. Automating _everything_  is not feasible and may bring more pain than advantages.

However automating repetitive, stagnant and boring tasks is viable and worth doing in almost all cases.

I even used to have that quote from Ayende as the motto of my blog: "If it doesn't move, kick it until it does, and then automate it".

I change that motto recently, but I still stand by it.

"Imagine your perfect environment, reading blogs, testing out the latest gadgets, working with the latest betas releases, contributing to open source.  Those things are all well and good but don't help the company make money."

This could be argued about, especially in the long run.

I think I'm missing something in the math. If you can build it in an hour and it usually takes users a minute to accomplish it, wouldn't your ROI come after 60 hours?

In any case, we can't look at ROI as a time factor. It has to be a percentage based on costs. And as Chad mentions, there is risk involved. How much do we pay the person to do it? How often does he/she make a mistake and what is the cost when that happens. Then, how much time to develop (including testing time and cost to fix bugs). Do the division and even then you're not done. Because presumably, you have other apps that need to be written. What is the ROI for them? And even if the ROI is higher than all the others, is it still "high enough"? I.e. is it higher than your baseline ROI (where you're better off putting the money in the bank)?

I...ummm....wanted to be an actuary when I was younger...

@Kyle

It's 1 min per month, so the 60 minutes to write the application wouldn't reach ROI until 60 months later.

As a huge PowerShell fan, I'll say that I try and show restraint in what I decide to automate. Sometimes that "quick script" takes an afternoon to get running and several hours to insert error-handling over time (as I encounter errors.)

On the other hand, sometimes the script that would "take too long to write" becomes such a burden that when I finally go ahead and write a script, it's like a giant weight is lifted off my shoulders. Almost magical.

I'm not necessarily disagreeing with you, just throwing out some of my own observations on when to script and when not to. Currently I'm leaning towards "script it, if only for my sanity."

Also something I'd like to see is a consistent way to report production script failures, i.e. if your service account's password expires and your script fails to run, how do we know it failed? There are a bunch of ugly solutions I employ to monitor job health, but I'm hoping for a better solution.

I tend to go for automation.  The mental weight of 1 less thing to worry about is _tremendous_ IMO.  As a developer, if I have to go through some word doc and follow a bunch of steps multiple times, that is waste.  Are you forgetting the DRY principle?

To be honest, the problem you presented isn't that difficult.  You don't have to be ayende to do that in < 1 day.

Go get some webdav library to connect to exchange, we use IndependentSoft, and I use Regular Expressions to parse the e-mail.  I actually do this for some of our systems that is run on a scheduled task to connect to an exchange mailbox and go through list of emails and process the ones it cares about.  It took me < 1 day and I am definitely not at the skills of Ayende.  But the thought of the emails being automatically processed without my intervention is worth it

I think it is important to maintain some sort of list or repository of these sorts of tasks, though, because the day may come when you have some other need to parse and extract info from, say, a weekly E-mail.  Maybe at that point, or when you have three items with similar needs, it starts to make sense to write something that can accomplish these needs and really get some benefit.

Of course, that day may never come; for now, as you said, just leave it alone.

I have seen a similar situation where an issue like this arose, and there was a determination that automation would not be worth the effort, but through the course of discussion it turned out that there already existing other opportunities to use the same would-be automation.  Of course, we still haven't implemented it, a year later, but the point is that the discussion is worthwhile because it may bear out other opportunities to combine similar tasks into one solution and build some consistency across the enterprise.  [Yes, apparently I just wrote "across the enterprise."]

As others have pointed out, automation isn't only about saving time, but avoiding errors. And the more the repetetive the task, the higher the risk.

One thing I haven't seen mentioned (maybe I missed it) is the process of discovery, the lessons learned, and the reusability that an automated solution can gain you.

Just the four tasks you named, (1)connecting to exchange, (2)scanning for a specific message,(3)parsing a message, and (4) feeding that information into another process, all valuable tasks that are easily paramaterized for reuse.  Now you have an exchange connector, a message folder scanner, a message parser, and a message data integrator. With those tools in your arsenal, you could now attack many other problems you never even considered automating.

But what if you never do get to reuse them? Well in that case, coding something like that sound like good exercise for the gray matter, and that's one of the reasons I'm in this field. It always pays to keep a sharp knife.

The problem with your argument is that it's not the time it takes to accomplish the task... it's the time it takes to do the task correctly.  Most of the time when i write an automation process that involves human interaction at some point, it will fail at the point the human has to interact.... and usually the more simple and mundane the task, the easier it is to forget to do it.

The problem with your argument is that it's not the time it takes to accomplish the task... it's the time it takes to do the task correctly.  Most of the time when i write an automation process that involves human interaction at some point, it will fail at the point the human has to interact.... and usually the more simple and mundane the task, the easier it is to forget to do it.

Pick of the week: The Holy Grail is NOT Automation General .NET 4 Cancellation Framework : A post by the Parallel FX team about how you’ll be able to build cancellation-aware applications in .NET 4.0. Why Defer Loading in Entity Framework Isn’t Going

At least the first part is automated. :D

I think it is important to maintain some sort of list or repository of these sorts of tasks, though.

Otherwise thanksss

I...ummm....wanted to be an actuary. I think it is important to maintain some sort of list or repository of these sorts of tasks.

YpdvsX Im obliged for the blog article.Thanks Again. Great.

HKxuYr Looking forward to reading more. Great blog post.Thanks Again.

145c8U Hey, thanks for the post.Thanks Again. Will read on...

o5K0Bp I cannot thank you enough for the blog article.Really looking forward to read more. Keep writing.

weS0TO Thank you for your post.Really thank you! Keep writing.

F8oMrz I really liked your article.

JbycJL Wow, great blog post. Cool.