When you think about it, there's really not much difference between our university's collective group of IT staff - the set of technology people from academic, business and administrative units, and ITS - compared with, let's say, Google. Sure, everyone talks about how smart they are, but so are we. Yes, they do have THAT DATABASE, but soon we'll be as tightly integrated in our divers operations. OK, so as of July 4, 2007, they have a market cap of 166.47 Billion U.S. dollars, but that's not a fair comparison since our university is a non-profit institution. So what's the big difference that really distinguishes us from a company like Google?
I propose that the big difference, and their real advantage, is their hive mind. Not quite like Borg, mind you. But they walk around with a culture in their head, and they are like-minded in this regard: they talk data. They gather it (with a vengeance), render it, analyze it, hypothesize it, and they talk about it. I know this because I read things that assert this with frightening uniformity, and I have a couple of contacts that have admitted as much. I have also noticed that many IT folks at our university don't have the same obsession for data. I'm starting to think that's a regrettable thing.
Take for example the group I know best and identify with most - our Web development community. Smart people doing lots of very cool stuff. Lots of them are database and scripting wonks, JavaScript and UI geniuses, gadget freaks (raise your hand if you were in line for iPhone D-Day), as well as chefs of tasty mash-ups. But how many of us test our work, gather data, and tweak our user interface based on that data? Hands up, please.
My hand isn't raised, either, mind you. Despite years of reading about best practices, I don't write and distribute code with unit tests; I don't even run the unit tests handed to me in open source code. (Now I'm off to execute runalltests.py - I'm thrilled!). I rarely run usability tests on application interfaces, so when I do it it's a big deal to design the test, find victims, find a quiet place, summarize data and make adjustments and test again... Why, because it's not routine. (I well remember testing an eCommerce application for an annual fund raiser, and it was crucial that I did so; and it's still running without major changes.) Ditto testing that doesn't require much work - standards and Section 508 compliance. And, interestingly, it's rare when I'm asked for results of tests. I say it's not routine and therefor more difficult than need be, but what I'm really saying is that it's not part of the culture we work in.
And if we don't test, or analyze our logs, how can we be sure that we're giving our stakeholders a good experience? I know I sometimes have a hard time finding information in our Web cloud. Developers are too close to their work to be good judges of quality and usability. But we're in a good place to be testers.