As a baseball fan, it's mindblowing to me that it took this long to actually read "Moneyball" by Micheal Lewis. If you're a fan of the game and like the stats side of baseball, it's an intriging read. I won't cover it too much here except to say that it highlights how one team - the Oakland A's - eschewed traditional approaches to evaluating talent and took a completely different approach to drafting players. It's incredibly eye-opening.

While reading it, a number of concepts stood out as transferable to technology and IT. One was this: that when evaluating things (talent in the book), the human eye, or the way we see things based upon "how we've always done it", can be deceptive. In many cases, stats can paint a very different - and more objective - picture of what's going on.

It reminded me of a regular question I ask datacenter staff (and related, moderately scientific study I've conducted) over the past 5 years. It goes something like this:

Jeff: "How many hours do you think you spend each week doing CLI work to accomodate either server updates or new application rollouts for other teams?"

IT Admin: "Well, it's hard to say. Maybe 5-10 hours."

Jeff: "Ever mistype something... say an IP address... and have to fix something using the CLI?"

IT Admin: "Sure - sometimes."

Jeff: "You know - you could probably automate some of that and reduce all typos... like fat-fingering of a .10 into a .100..."

IT Admin: "Yeah - but - that might take me a few days to build and this is working alright."

This seems reasonable. However, in reality, that 5-10 hrs is usually more (I've had people track this and realize it's closer to 25 hrs). And, based upon accumulated examples from a wide range of customers, CLI-work has roughly a 30% error rate. Acceptable? Maybe. Ideal? No so much.

The deception comes in here... Add up that 10 hrs (conservative for many) for a typical work year at we're talking about 12.5 weeks of effort. That's more than a month! What if you could build an app using iControl to automate some of these routines? Say it takes 2 weeks of effort...

Wouldn't you trade 2 weeks to get another 10 back to do other things on the list that never get any attention? (and - reduce those CLI errors to virtually zero in the process... and get fewer, screaming calls from application owners?...)

The point is this: doing it the same way it's always been done conveniently deceives us. We lose track of the time we spend... we don't evaluate it for what it is vs. what we think it is...