Lazy Developers

On The Museum of Curiosities on BBC4 radio one of the topics last week was ‘What do you consciously do repeatedly which is stupid?’ One of the examples they gave was a cleaner who cleaned the same lift twenty-five times in a single day. He thought it was a different room on each floor!

Undoubtedly funny but I’m not sure it answered the question because surely he wasn’t conscious of the stupid action. It got me wondering about what I do repeatedly that is stupid.

It’s much harder to answer than I first thought. I’ve been working at the same company for nearly fifteen years because it’s on my doorstep, convenient and I quite enjoy it. There are undoubtedly better opportunities up in the big smoke. But I’m not sure that’s stupid it’s just sensible.

Figure 1

A member of my team retired recently and he left a legacy system for the rest of my team to support. One of the support activities is to import data files into the system when the client emails them to us at random times throughout the week. The process starts with a number of manual steps such as saving the email attachment, checking it, and copying it onto the production server and then completes with a final automatic step that imports the data.

This is clearly stupid. Not only is it time consuming performing all the manual steps when the complete process could be automated, but it is very disruptive to other activities, we have to drop everything and import the data when the email arrives unexpectedly. And that’s only considering the impact on us, the client emails the file and then has to wait an unknown amount of time for their data to appear in the system – our support person might be on a tea break, in a meeting or on holiday.

Last week I was sat in a presentation given by the head of development at Lotus F1 and he showed a slide of his development team with their feet up reading books. The caption on the slide said ‘Only ever employ lazy developers.’ Obviously the picture didn’t reflect the sentiments of this expression.

I’ve come across this suggestion a few times in the past, most recently in a presentation by our CIO where he was talking about encouraging the business to ‘Automate the Norm’. It’s the same thing, in other words you don’t want your developers spending time performing manual processes when they could spend a little effort up front to automate them and free themselves from the task in the future – not so that they can put their feet up and read but perform some other more productive tasks.

One of my other colleagues illustrated this very nicely on his blog a few years ago with the graph shown in figure 1. I’ve changed the labels to match what I’m talking about here.

The key to success with this graph is deciding at what point to write an automation process, they aren’t always simple things to write and sometimes they require ongoing maintenance (the graph doesn’t reflect this) so writing one before the first manual iteration is probably not a good idea. Personally I put it off until I get fed-up of doing it manually.  

The other thing that needs to be considered when creating the automation process is what tools to use. If we want to introduce ‘Automate the Norm’ as a principle in our IS team we need to ensure we have some design patterns and the appropriate tools for the job.

If we consider the data import example, SQL Server Integration Services (SSIS) is pretty good at doing that but if the file of data is uploaded on a website by one of our clients then getting an SSIS package to process the data and return the results to the user is difficult. If the client is emailing the data file to a shared inbox the task is even more difficult, I assume Biztalk could be used in this instance but it’s not readily available (i.e. licenced) to everybody in the team.

There is one other wrinkle to creating automated processes to save time, lots of people in our business are consultants and they charge the client by the hour, if we automate the manual processes that they perform we reduce the number of hours they can charge which affects our profit. This is an old fashioned non-client centric mentality which thankfully we are slowly getting away from.

Now what stupid things do I do repeatedly?