Repetitive manual activities are delivery risk and operational uncertainty working under the sinister guise of an honest day’s work. No more, no less.

As a manager, you want to create an environment where repetitive manual tasks and ad-hoc firefighting are the exception rather than the rule for your developers, DBAs, and sysadmins.

For example, you want an environment where sysadmins kick back and read IT magazines occasionally, because their run-of-the-mill administrative tasks (adding users, managing disk space, etc.) are all scripted and/or automated. They can then focus their energies on the unexpected and unavoidable issues that crop up from time-to-time. Plus, since they aren’t running around five (or six) days a week constantly putting out fires, they have the mental capital to make short work of whatever Murphy’s Law happens to throw their way. To the outsider walking past the data center window, the Information Week -reading sysadmin may appear lazy.

But, truth be told, they’re “lazy” in a good way.

World-class IT and software shops realize that automation is not a technical thing, but rather a cultural thing. The best teams celebrate those who sit back and let their computers do their work for them. You want to have a project team that considers repetitive development activities to be tasteless. Sometimes necessary, but generally frowned upon.

This is also a case of something being good for the team and good for the individual at the same time. For the team, process automation yields greater consistency and predictability. For the individual team member, automated builds, scripted deployments, and the like often mean the difference between going home and watching The Simpsons with dinner at 7PM, or going home and watching it Tivo’ed with your re-heated dinner at 9PM.

This does not mean that everything that can be automated should be automated. Examples include:

• Inconsequential one-time tasks. Note that one-time tasks of consequence may be good candidates for automation, so that the heat of the moment doesn’t introduce human error
• Tasks involving a high degree of uncertainty and variability, where the effort to catalog and account for all of the possible yet unlikely scenarios outweighs the benefits of hands-off operation.
• Tasks where humans run circles around computers in detecting errors, anomalies, or even success. For example, it’s tricky to automate the process of determining whether or not a web page with dynamic content “looks right”. Sure, you could assert the presence or absence of specific text, and you could also do image comparisons for static sections of the page. Alternatively, you could have someone who knows what “right” looks like take 2 seconds to look the page over and give it the ol’ thumbs up or down.

Fortunately, software development has tons of tasks that are good candidates for scripting and automation, including:

• Development environment configuration
• Database Administration
• Software Builds
• Software Deployment
• Testing, both Unit and Regression Testing
• Transformations, such as converting the data contained in an Excel spreadsheet into SQL INSERT statements

How do you know when you’re striking the right balance? As a general rule, you should walk through your entire end-to-end process and identify the areas that you have automated and not automated. This will at the very least provide a rudimentary roadmap for process improvement. You’ll know that you’re in good shape when there is a specific reason why each manual process is still done by hand.

It’s also a good sign if you start noticing dog-eared Python books showing up around the office.

Larry Wall, the creator of Perl (a very popular programming language) says that the three virtues of a programmer are Laziness, Impatience, and Hubris.
As a project team, you always want to “Maximize the work that you don’t have to do”. This does not mean that you are lazy, either in the negative sense or even in the strict Larry Wall sense. What it means is that you are actively identifying the areas of low-value work that you could reasonably do in the course of the project, and INTENTIONALLY NOT DOING THEM.

By specifically identifying the things that you aren’t doing (the anti-requirements, so to speak), you are doing two things:
1) Reinforcing the focus and scope of the real work at hand
2) Taking a second pass through the out-of-scope activities to ensure that they are not required.

One of the best and worst uses of time on a multi-person project are the inevitable debates around architecture and design. Unfortunately, these debates can sidetrack the participants, and become a mano-a-mano test of debating acumen, neither of which are especially conducive to producing software on time. This article discusses the value of a shared philosophy among team members.
Linus Torvalds (of Linux fame) has a saying that “Many eyes make all bugs shallow”. Similarly, project teams should have a process whereby the collective wisdom of the team members should cause Bad Ideas to die a quick and painful death.

The challenge with this is that it is often difficult to separate the message from the messenger. While the senior folks on the team are usually correct more often than their less-experienced counterparts, this is not always the case.

In order to keep lively debates from devolving into a “spitting contest”, euphimistically speaking, it’s important to allow Bad Ideas to die with minimal collateral damage to their creator.

The way that we do this is simple: We set out early on the project to gain consensus on a number of core principles or beliefs that the team has about the project and the resultant software. These are often broken out in terms of:

• People Issues (User experience, stakeholder expectations, team member specialization, etc.)
• Process Issues (Requirements management, testing strategies, build/release management, etc.)
• Technology Issues (platform considerations, “No Premature Optimization”, role of database, etc.)

Once we have consensus on the high-level beliefs, then many subsequent debates can be judged not solely on their individual technical merit, but also in terms of how well-aligned they are to the higher principles that the team is marching toward.