When to automate?

Automation is always good when in context. This is what the software industry is all about anyway, automation of most of the repetitive tasks.

But as a software developer what have you done to make your job easier? We keep developing tools and systems for other parties. Though it is us who need those tools because it is us who are doing the repetitive tasks all the time.

So a better question than "When to automate?" 'd be "What to automate?"

Personally speaking, I tend to automate testing. A while ago I was working on a web application that required upload to a test FTP server. So whenever I changed an asp file or re-compiled a FLASH movie, I had to manually upload those files to the FTP server. Of course that didn't work, and that was when I started looking out for ways to automate the whole process. I came up with a very simple solution which is using the built-in windows FTP command which supports scripting. (ftp -s:filename)

That saved me a lot of time back then. And we are not even talking about Code Generation or batch updates.

Beside testing, there is a list of things that if automated could make your life easier and help you spend more time on stuff that matters instead of doing repetitive boring tasks.

For instance if you are doing some C# development for windows, you probably have been bored writing properties and private members for every new class you add to your solution. Though C# 3.0 supports automatic properties now. Still it is a boring task. Others include adding error providers to a windows form and handling the Validated event for every control.

These are just example of repetitive tasks that are actively killing our time and minds. If you feel you are wasting time on such tasks, consider automation. Spend some of your time on developing tools for YOU! I have done that and it really saves me a lot of time and helps me focus on more important stuff.


For example a while ago I wrote a very small tool that does the following:
1 - Generates class member variables and properties.
2 - Generates error providers and generate validation events.
3 - Creates temporary text files for me for my todos and so on.
4 - Takes screenshots helping me when I want to demonstrate something to someone or for use in emails and reporting bugs.

Below is a screenshot of that tool.

Developing it took me less than 4 hours, thats less than half my working day. BUT saved me infinite hours of hitting my head against the wall.

I am planning to develop a similar tool to help me with my SQL tasks soon.

Exception handling versus error codes

A while ago, I was really lost between throwing/catching exceptions and returning error codes. After doing some research I have reached the following:
Exception handling is usually expensive due to the stack unwinding process, specially when it is not caught near where it was thrown.

So you can't just go throwing an exception for every trivial error or an invalid input to a procedure. This leads me to believe that a good approach 'd be to check all the inputs given to a method using normal if/else blocks,returning failure status or error codes when something goes wrong or wrong input is provided and only throwing an exception when a fatal error occurs.