The Holy Grail is NOT Automation

image Often times as developers who understand what computers can do is really limitless, we seek to automate everything.  The holy grail is being able to sit at where everything is accomplishable with a simple double-click. Often times automation, however wonderful or geek drool inspiring, is not cost effective.

Once a month we have to update sales tax rates in our system.  We have a program that does the update but needs two vital pieces of information which are supplied to us a few days before the end of the month via an email.  These two pieces of information are a download file location and a password.  We enter the two pieces of information as command line args to the program and off we go.  The whole process takes about a minute.

While running the update today there was a brief discussion about how we could possibly automate the whole process.  Ideas floated around like reading the email and parsing the text for the download location and the password.  In order to do this we'd have to write an program which:

  • Can connect to our Exchange server or a mailbox on our system
  • Scan the inbox for the particular message you are looking for
  • Parse out the two pieces of information from the email
  • Launch the original program passing in the two pieces of information we just gathered

Let's say for a moment that you're a good programmer. I mean ayende good.  How long does it take you to write this? An hour? Two?  Ten? A week (40)?  Let's be real aggressive developers here with over-inflated sense of skill for a moment and say we can do this and have it production ready in an hour.  If it takes us a minute to run by hand, then it will take us 5 years to get a return on the investment we put into the project.  If we're more down to earth and estimate the project takes 10 hours, we will absolutely never see a return on that time spent because your application which needs the tax information will be rewritten, trashed, or abandoned long before the 50 years it would take to start seeing a return.  I was glad to hear it when my fellow developers came to this conclusion as well.  Automation is great to a point when it saves time.  Any effort beyond that is hard to justify and could be seen as wasteful.


Posted 05-28-2009 9:05 PM by Tim Barcz
Filed under: ,

[Advertisement]

Comments

Liam McLennan wrote re: The Holy Grail is NOT Automation
on 05-28-2009 10:56 PM

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.

Chad Myers wrote re: The Holy Grail is NOT Automation
on 05-29-2009 1:20 AM

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

Morten Lyhr wrote re: The Holy Grail is NOT Automation
on 05-29-2009 2:17 AM

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?

sotto wrote re: The Holy Grail is NOT Automation
on 05-29-2009 3:09 AM

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?

Derik Whittaker wrote re: The Holy Grail is NOT Automation
on 05-29-2009 8:13 AM

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

Tim Barcz wrote re: The Holy Grail is NOT Automation
on 05-29-2009 9:07 AM

@Chad

As far as risk goes you are correct.  It's something that was implicitly factored in but I didn't realize I did until I read your post.

There are roughly 41000 zip codes that we track sales tax for.  In a given month there may be five that change.  Of the five that change the likelihood that we have nexus (we have to charge tax) in that zip code is relatively small.

So while I didn't describe that I factored in risk, I did, which should have been noted.

Tim Barcz wrote re: The Holy Grail is NOT Automation
on 05-29-2009 9:09 AM

@sotto,

I'm all for developer satisfaction.  And it IS important to me both as a developer myself and as a manager.  However the satisfaction of a developer is generally far less important than the value the developer brings to the table.

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, which is ultimately why you're hired somewhere.

Krzysztof Kozmic wrote re: The Holy Grail is NOT Automation
on 05-29-2009 9:40 AM

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.

Krzysztof Kozmic wrote re: The Holy Grail is NOT Automation
on 05-29-2009 9:41 AM

"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.

Kyle Baley wrote re: The Holy Grail is NOT Automation
on 05-29-2009 11:10 AM

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...

Chris Missal wrote re: The Holy Grail is NOT Automation
on 05-29-2009 12:17 PM

@Kyle

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

Peter wrote re: The Holy Grail is NOT Automation
on 05-29-2009 4:14 PM

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.

joey wrote re: The Holy Grail is NOT Automation
on 05-29-2009 5:10 PM

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

Jay wrote re: The Holy Grail is NOT Automation
on 05-29-2009 8:30 PM

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."]

Hadi Hariri wrote re: The Holy Grail is NOT Automation
on 05-31-2009 3:01 PM

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.

John wrote re: The Holy Grail is NOT Automation
on 05-31-2009 9:23 PM

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.

Zac wrote re: The Holy Grail is NOT Automation
on 06-01-2009 3:32 PM

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.

Zac wrote re: The Holy Grail is NOT Automation
on 06-01-2009 3:34 PM

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.

Code Monkey Labs wrote Weekly Web Nuggets #66
on 06-02-2009 2:52 PM

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

Robz wrote re: The Holy Grail is NOT Automation
on 06-03-2009 2:30 PM

At least the first part is automated. :D

Latif wrote re: The Holy Grail is NOT Automation
on 06-09-2009 12:17 AM

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

Otherwise thanksss

Think Flick wrote re: The Holy Grail is NOT Automation
on 07-17-2009 1:18 AM

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.

buy viagra online wrote re: The Holy Grail is NOT Automation
on 02-02-2013 11:14 PM

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

buy viagra wrote re: The Holy Grail is NOT Automation
on 02-02-2013 11:14 PM

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

amazing site wrote re: The Holy Grail is NOT Automation
on 03-03-2013 8:24 PM

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

bookmaring service wrote re: The Holy Grail is NOT Automation
on 03-15-2013 4:49 AM

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

buy social bookmarks wrote re: The Holy Grail is NOT Automation
on 03-24-2013 2:40 AM

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

social bookmarking service wrote re: The Holy Grail is NOT Automation
on 04-19-2013 9:58 PM

F8oMrz I really liked your article.

digital camera guide wrote re: The Holy Grail is NOT Automation
on 05-14-2013 7:51 AM

JbycJL Wow, great blog post. Cool.

awesome moldavian news wrote re: The Holy Grail is NOT Automation
on 08-04-2013 6:44 PM

cFS8Pv Thanks a lot for the blog post. Really Great.

link building team wrote re: The Holy Grail is NOT Automation
on 10-01-2013 9:09 AM

9WNt7q Thanks for the article.Really looking forward to read more. Great.

best link build wrote re: The Holy Grail is NOT Automation
on 10-15-2013 7:08 AM

AvHt1t I loved your blog.Really looking forward to read more. Will read on...

link building wrote re: The Holy Grail is NOT Automation
on 10-26-2013 1:10 PM

pahcZK I really like and appreciate your blog article.Much thanks again. Will read on...

check this out wrote re: The Holy Grail is NOT Automation
on 11-20-2013 5:10 PM

jLSHjL I really liked your article post. Really Cool.

stunning seo guys wrote re: The Holy Grail is NOT Automation
on 01-21-2014 8:10 PM

drvmIV I am so grateful for your blog post.Much thanks again. Great.

nice seo guys wrote re: The Holy Grail is NOT Automation
on 03-25-2014 2:13 PM

ck8Xla Thank you ever so for you article.Thanks Again. Much obliged.

stunning service wrote re: The Holy Grail is NOT Automation
on 04-05-2014 2:56 AM

aoE62G Thank you for your blog article.Really thank you!

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)