The Rule of the Lazy Class, or Why The Puritan Work Ethic Has No Place in IT
An Introduction to AutomationAugust 17th, 2006 by admin
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.
August 17th, 2006 at 2:03 pm
I doub’t you’d see even automation gurus just sitting there and countin the pixels on their screen. Rather, any time they are not putting out fires they will be furiously writing more automation.
August 17th, 2006 at 2:48 pm
Like any service-orientated role that requires you to be “on-call” for when things go haywire, sitting back and kicking up your feet is a generally a sign that you’re doing your job well. Take the complete lack of any catastrophe after the Millenium bug… Repetitive tasks aside, nothing happening means the right things happened in the first place.
August 17th, 2006 at 3:45 pm
Software related stuff is good candidate for automation.
Buiding network and systems (to some degree) is not!
Sitting back and reading and IT magzine is not “lazy” it is educating your GURU with new tech’s and methodologies which are in turn good for a company. I’d like to see a CFO come up with a rock solid and secure backup plan for the financial data.
August 17th, 2006 at 9:21 pm
Personally, I agree that “lazy” is the way to go. If your tech guy or programmer is reading tech magazines and in general seems to be very content, then the right things are happening. Minimal support calls are coming, and the stuff that can be automated is being automated.
I would extend the meaning of “lazy” further to include incidents where something was done right the first time, instead of having to be revisited many times. The first “lazy” attempt at something takes longer than just a normal throw-it-together attempt, but the throw-it-together attempt will result in many more hours being spent revising the solution. In short, be “lazy” and spend some time thinking about the problem so that you can prevent having to revisit it many times in the future.
August 17th, 2006 at 11:34 pm
[…] From Approach.Botonomy.Com (ht REDDIT), an article of the philosophy of successful computer systems administrators: 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. […]
August 25th, 2006 at 2:11 am
[…] Another post also wants IT people to be lazy: 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. […]
August 29th, 2006 at 8:39 am
[…] The Rule of the Lazy Class, or Why The Puritan Work Ethic Has No Place in IT. […]
September 10th, 2006 at 3:04 am
[…] Sehr schönes Posting über “Faulheit” in der IT: The Rule of the Lazy Class, or Why The Puritan Work Ethic Has No Place in IT. […]
September 27th, 2006 at 2:07 pm
[…] Approach.Botonomy.com has an interesting article on Why the Puritan Work Ethic has No Place in IT. […]
November 1st, 2006 at 9:57 pm
[…] This is not to overemphasize the other end of the curve, but in the present culture, there’s little concern of that being done. The Puritan Work Ethic Has No Place in IT. Do good work, not a lot of work. […]
October 11th, 2007 at 3:22 am
[…] http://approach.botonomy.com/2006/08/17/the-rule-of-the-lazy-class/ […]
January 3rd, 2008 at 12:16 am
The Ominous Thoughts News Report…
The Ominous Thoughts News Report 3.25.07411mania.com, TX -Mar 24, 2007Hulk Hogan was on the Bubba The Love Sponge Radio Show this week…
April 11th, 2008 at 1:52 am
Lately I have been trying to find any kind of information for my project, but unsuccessfully. Now it seems like I finally found a lot. This is the greatest site among all internet-sources.
July 30th, 2008 at 8:34 am
None…
None…