It’s Monday, the last day of the iteration. It’s time to build, package and release the next version of LogLady, the best tool known to man used for analyzing server logs. Robert, the build master, responsible for the buildprocess dreads this day more than any other day of the iteration. To Robert this isn’t release day or the last day of the iteration. It’s Build day … yuck.

Another build master is born

Robert whips up the command prompt like he usually does and wonders what kind of surprises he’s going to run into this time. Gentlemen, start your engines. But first, compile time. We copy the copy source files, from this directory here over to the build dir. Then compile. The actual compilation wouldn’t have been too bad if it weren’t for the circular dependencies and other interruptions, Robert thinks, as he heads to the coffee machine while the compile is running. I’m going to need this second cup. What he doesn’t know is that it will take him more than 10 cups before he’s going to be finished, this time.

It comes as no surprise; the build crashed after 4 minutes. A new record Robert thinks to himself as he takes a sip of his blant coffee and searches the command history for the command he usually runs when this happens. Got it, he executes his ‘cleanup command’ and then resumes the compilation. That should do it. He takes another sip of the coffee and starts browsing the net while the build splurts out loads of text and debugging-info in a barely visible terminal, behind his Internet browser.

Suddenly, the text stops scrolling and Robert is snaps out of his zombie-like state. Ugh, what’s this, oh no, not again. Another third party library that isn’t on the build path. It isn’t even two weeks since this happened the last time. Why don’t they bother to put these files in the version control repository. Robert searhes the net for 15 minutes before he finds the correct version of the 3rd party library and is able to put it on the build-path. Then he resumes the building and starts browsing again.

Over and over and over again

After three more interruptions, the day draws to an end. But before he can release the code it has to be obfuscated and packaged. The zip has to go into version control and documents has to be updated. The work spills over to a second day. Two days become three and even more work is needed.

Then, just as he is about to tell the productmanager he’s done; a bug is discovered.
Robert isn’t very happy. In fact he’s pretty darn pissed. But he starts over, thinking, ‘Well, someone has to dig in and do some real work for a change’. He hasn’t realized it. But one iteration from now all he will be doing is managing releases.

The way out

Doing things, by hand, that can be done by computers is not only wasteful, it’s degrading. It sucks the energy out of you and your team members. This energy and time could be used to improve other parts of a software development process. Or pieces of code. Or maybe plain testing.

In short, automation scales very well. It’s a much more linear function than adding developers. Add one computer and you can probably run tests, build code or do any other task twice as fast. As longs it’s fully automated.

Before you automate anything though, you should make sure you can do it by hand. If you can’t do it by hand, chances are it’s very hard to automate. If not impossible.

Beware. Everything that can be automated shouldn’t and everything that seems like it couldn’t should be tried. Let me explain.

When you’re automating you are adding tasks to your process. This makes them harder to question, get rid of or improve. Because you might not really know why they are there. Or rather, why they became part of the process. Therefore you should simplify the things you are automating /before/ actually doing so. That way it’s easy to see where everything fits in.

Simplify, then automate

Things that can’t be automated requires an extra look as well. Why can’t they be automated? The very questioning may lead to insights and later even changes to a process. So, When looking at the same piece of work again you might spot a way to automate it.

Signs that indicate ‘computerwork’. Things that could be automated

  • Repeatedly doing the same thing
  • A problem seems too simple to be automated
  • You often miss important steps while working
  • Your mind wanders while working. It could also indicate that you need a break.

There are probably more signs. Can you think of one?

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

One response »

  1. Mr. Hericus says:

    Very nice article, and right on the spot. Don’t just automate every step because that’s the way it’s always been done. Automate because it saves time and frees you up to really look at the whole process and see where optimizations can be made.

    Thanks for the post!

    Mr. Hericus

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s