Friday, December 19, 2008

Automation

I get bored easily. I wouldn't make a good factory line worker because I'm horrible at repetition. Once I've figured something out or gotten proficient at something, I lose interest for the most part (this excludes multiplayer first person shooter games - I can play those forever). If I had to choose between working on an assembly line or wrestling rabid alligators, I would probably say something like "How big are the gators?"

This isn't necessarily a bad thing (or at least that's what I tell myself). When it comes to building software, I like to design and code, improve process - that sort of thing. Doing repetitive things like running database scripts or running reports on project status are Kryptonite to me. I would rather spend a few days building a tool to do the work for me than do it by hand every day / week, etc.

What are good candidates for automation? Pretty much anything that is repetitive.

Daily, Weekly, Monthly, Reports.
Do whatever it takes to make these pushbutton. This doesn't apply to one off reports. However, if you're spending a bunch of time copying and pasting between Excel spreadsheets, you're doing something wrong. If you automate the reporting process, any time spent daily is tweaking. Tweaking is important for reporting. If you're expending all of your energy just perfoming the mechanics of assembling the report, you're not as likley to make improvements to the report itself.

Builds.
Find a way to automate the build. This is a continuous integration sort of thing, but it's a productivity enhancer. Broken builds make broken teams. Can you live without it? Sure, on a small team it isn't too bad and I've worked that way plenty. However, on a larger team, I can't imagine living without it.

Installers

If you're using the Setup project type in Visual Studio, it's pretty easy, just build the setup project from the IDE. If you're using install shield, find a way to script it / run it with nmake, etc so that you don't need the "install guy" (who is probably a coder responsible for a bunch of other things) to take time to "turn the build" and make an installer.

I ran into an extreme version of this at one shop where the build took something like 14 man hours to turn. This one guy would go back to the build machine (it was the only environment where the build would work) in the closet and do his thing. He eventually figured out how to script the whole thing with make files, but the manual process was ridiculous.

Odd bit
There are plenty of opportunities. While working at one place, the shiny new web server got set up just before the IT guy left for vacation. Genius. Of course, the site developed all sorts of problems and was going down every few minutes.

We fixed the (numerous) issues and put it back into production. This one guy was sitting there hitting the web site every few seconds to make sure that it was staying up. I threw together a quick app that monitored the site and would make noise if the site went down. He appreciated the help but was like "You must have too much time on your hands." My response was "that's how I make time." I try to invest a little bit of time up front so I don't waste time later. It's a net gain.

No comments: