Medieval Help Desk

For all of us who help users.... I love how both the techy and the new user struggle to control their irritation and keep a friendly tone.

Biases that block effective problem solving.

All the best problem solving techniques can be defeated by biases that get in the way of clear thinking. And the worst of it is, we can't often tell when we are in the grip of these patterns. There are three we've seen often in our work that having a major impact on technical problem solving. One is what my wife refers to as "The Hot Dog" syndrome. Michael Anissimov calls it "The widespread tendency to categorize oneself as above average ". Certainly we techies tend to think of ourselves as a clever lot; this can cause us problems when it encourages us to disregard input from others, to discount the possibility that we made a mistake, act without due dilligence, or so often to underestimate how long it will take us to do something. It also contributes to the oft-cited failing of Not-Invented-Here, where a techie will devote a week cobbling together a solution to a problem rather than buying a two-hundred dollar utility to accomplish the same task. A countervailing bias is the "Cover your Ass" syndrome [CYA]. Since in real life a large number of the problems a techie is called upon to solve are problems she may have played some role in creating, the need to defend one's reputation really is inherent in every IT crisis. It affects problem solving: I really don't want to find out that the reason no credit cards have been processed for three weeks is because I reconfigured the firewall. So I instinctively look for changes other people, other vendors, or other departments made. In organizations where blame is a big part of the culture, CYA can have a major effect on problem solving. Organizational culture can play a significant role in keeping people from thinking straight. I was talking to a client the other day who referred to the change log in our application as the "Blame" table - you go there to see which of your co-workers is to blame. Really striking. I've heard other users in their in-house training say "This is how you can find out who knows why a particular change was made". Quite a difference. Be on guard in particular for teams that need to affix the blame before attempting to solve the problem. Another important bias is one Groopman in his article called "Availability." This bias is more cognitive than emotional, and reflects our tendency to stop at the first two or three possible solutions that come to mind, that are the most available to us. It can mean that it does not occur to us to seek additional information when we should, because we immediately apply one of the first few solutions that come to mind. I'm thinking of a time when I was given an old mainframe printer. I wanted to hook it up to a computer, but it used the pins in the parallel interface differently than the PC did, so it would not work when I connected it. I'm a software guy. So the solution that occurred to me - that was available, was to write a routine that hooked into the interrupt handler for the parallel port and changed each character's pin out as it was transmitted. It worked fine, but it had to be loaded when the computer was booted, and then prevented any other printer from being used on that port. What I should have done was make a custom cable. Duh. What is the value of categorizing these harmful patterns? Giving patterns names can help us recognize them. For the negative patterns or biases, this enhanced recognition can help us avoid falling into them. The first two biases often have feelings associated with them -- if I'm sweating bullets while I work on something, I'm vulnerable to CYA. If I'm showing off to my client, I might be a Hot Dog victim. The third one is most insidious, and leave fewer traces. If we are moving very quickly to a time-consuming or expensive solution with a sense of certainty that we know what to do, or if we are feeling a sense of time pressure, we may be in the availability trap.

Rules of Thumb

Jerome Groopman is a physician who frequently writes on medical topics for the New Yorker. His stuff is always fascinating. A few issues back, they ran a piece of his called What's the Problem, where he looked at the heuristics, or rules of thumb, that physicians use when making a diagnosis. And at certain recognizable errors doctors make that lead to incorrect conclusions about a patient's ailment. Ed Batista, in a post called When Heuristics Go Bad, immediately picked up on how the same kind of analysis Groopman uses can be applied to management decision making. And I thought, this explains so many problems I see in non-profit IT teams, especially those consisting of Accidental Techies. Where's the buzz? There are three heuristics that guide me through 90% of the problem solving I need to do. The first is one I learned when I was 12. I call it the "Where's the buzz" rule. If your stereo is buzzing, how do you decide which component is buzzing: the speakers, the cd player, or the amplifier? By removing each component from the mix and seeing if the problem goes away. Try using the same speakers and cd player, but another amplifier. If the buzz goes away, the problem is in the amplifier. This same approach is a great tool to apply to IT problems like why your meetings registration web pages no longer will charge credit cards. I'm always surprised to see people who have never added this trick to their toolbox. What did you break this time? Everyone knows that half the time when you try to fix something, you break something else. When I change a light bulb, I scratch up the walls carrying the ladder back to the basement. When I refine the security settings on the firewall, ecommerce goes down on the website. This is not just an annoying fact of life - it is a valuable trick for problem solving. When a new problem emerges, the first rule to apply should be "What has changed?" Odds are the last changes made to your software, to your network, to your pc, have caused the new problem. When sorrows come, they come not single spies, but in battalions The Bard can add a third heuristic to this set. So often, several problems emerge all at once. I've found that when this happens they may well have the same cause, even if this seems really unlikely at first glance. So pick the one that looks easiest to solve, and see if this resolves the other problems as well! But as Dr Groopman points out - even with a some useful heuristics at your disposal, things can still go wrong. Tomorrow we will look at a few common patterns that defeat effective problem solving.

Daylight Saving Time and Windows

A number of my clients have asked me recently if they need to be worried about the early change to daylight savings time this year. You remember, don't you: clocks get rolled forward on March 11th this year as the new law lengthening Daylight Saving Time takes effect. Here's the deal: The Windows operating system assumes it knows when to start Daylight Savings Time in the United States. If you have installed all your OS updates - and you are on XP, 2003, or Vista - you should be fine. But if you are still running Windows 2000, your clock will not change properly. No daylight savings time update has been released for Windows 2000. According to the always helpful Geeks are Sexy blog, Microsoft is releasing patches to update 2003, XP, and Vista to the new 2007 Daylight Saving Time. They will not release a patch for 2000, and customers are told to manual patch their OS via a few registry tweaks or to simply upgrade to a newer version of Windows. If you have a large Windows 2000 installation, you might want to look at a utility from IntellAdmin to handle this for you. There's even bigger worries for is users of Microsoft Exchange Server 2000, for which no free patch will be made available at all. Check out the links on that Geeks are Sexy post for much more information and lots of links on how the time change will impact Windows, Outlook, and Exchange Server.

The Dixie Chicks and Hambo in the Snow

I don't usually pay much attention to the Grammys, but there was so much reason to this year. National attention was focused on the resounding show of support for the Dixie Chicks and their right to speak their mind those many months ago about the president and his war. The endless stream of "bests" was clearly political - but quite gratifying. Nonetheless, I wouldn't have minded if they had lost in just one category - Best Country Vocal Performance by a Group or Duo: my friends in The Duhks were also nominated, and I would have loved to see them take home a prize. I'd never been aware of the extent to which traditional and folk music is both honored and slighted by the Grammy's. Honored, in that there are a world of catagories for the kinds of music I love. Slighted, as these are never mentioned from the podium and rarely in the press. I'm only aware of it this year because our very good friend Andrea Hoag was nominated this year in the World Music/Traditional genre, for the album Hambo in the Snow along with with Loretta Kelly and Charlie Pilzer. Here's a great NPR piece about them. Andrea is my wif'e's fiddle teacher! Click their picture above for a bit of their music. Other traditional musicians we love were also nominated for awards. The insanely innovative Casey Driessen was nominated for Best Country Instrumental. Sadly, neither he nor Andrea went home with the victrola. But the New-York based Klezmatics took the World Music/Contemporary prize for their up-to-date take on the traditional Jewish Klezmer sound. And in other victories for traditional music, Bruce Springstein was rewarded for his venture into the folkie world: he took home Best traditional Folk Album for his all-Pete Seeger venture, We Shall Overcome: The Seeger Sessions.

Monday Morning Links

Management Tools 2007 I found through Steve Shu's Blog a link to the Bain and Company Management Tools 2007 Guide. Food for thought for anyone working to re-imagine their organization, the guide consists of single page introductions to each of 25 management tools or processes, with an extensive bibliography on each. Just ask your users? In a recent post, I pointed to some writers on software testing who suggest that users are not the best testers of the applications they are going to use. They are just too close to the whole project. In a related vein, Neill Archer Roan suggests that getting too much input from your current customers can stifle innovation. Again, because they are too close to the product. Asking customers about what they like or dislike about the current product or service will cause them (and you) to focus on incrementally improving what’s current. While I’m not against incremental improvements in products and services (I think they are very important, indeed), this focus won’t lead to innovation. We've seen this in our own little company. Those of us meeting with prospective users are hearing feature requests and other feedback that we've never heard from our current clients. So if you are trying to make a quantum leap in the appeal of your products, services, or campaigns, you've got to solicit input from outside your current community. Pondering Windows Vista. Windows Vista has been available commercially for a few weeks now. We've been running a beta version on a few machines for about six months, and just last week I purchased a new laptop for myself with Vista Home Premium installed. We've had to wrestle through some compatibility issues - and some of the vendors whose tools we use have still not solved all their Vista problems. If you are pondering an upgrade for your organization, I'd recommend setting up Vista on one machine and verifying that all the software you routinely use in your organization is happy before you consider a company wide rollout. Confused about all the flavors of Vista out there? Get your bearings by consulting Windows Vista: A FAQ for Non-Profits posted on the TechSoup website. And expect a bit of a learning curve - even the Start menu works differently. Members Only run fine, I'm glad to report - although of course the Windows Help files no longer are supported. Media that Matters. My cousin Julilly let me know about a short documentary by a 17 year old American filmmaker that is really quite disturbing. Take a look at A Girl Like Me by Kiri Davis at the Media that Matters online film festival.

Software for Free?

We've seen some vendors price their software by the number of contacts in your database. By the number of emails you send. By bandwidth used. We've chosen to do it by the staff size of your organization, licensing the software by user count. The idea is to be fair - to charge less to the smaller organization. To charge more to the organization making more use of the tools. But sometimes this doesn't work. There are organizations with quite a few full-time staff members, squeezing by on a very tight budget and doing very valuable work. Our pricing plan just doesn't help them. They really need the software - but they need way more licenses than they can afford. To enable some organizations in this bind to obtain the software they need, we've decided to give away one system each quarter. Here's the full announcement. Drop Doria a note if you are interested.

Improving Public health in Mali

Last month I wrote about my stroll through Sikoro, on the northern outskirts of Bamako, Mali, and the community health project Siguida Keneyali we learned about there. Today my friend Britt Bravo posted an in-depth interview with Caitlin Cohen of Siguida that looks at the project and its community-based orientation in some real detail. I'm sure you'll find it a worthwhile read!

Testing more than the features

One issue you can never discuss too much is testing. How do you test a software application before turning users loose on it? Dr Dobbs, one of my favorite software magazines for almost two decades, had a nice piece by Scott Ambler on test in the December edition. Scott has emerged as one of the principal evangelists of the agile development movement, and in this issue he discusses testing from an agile perspective. Like much current writing on testing in the Extreme Programming and Agile universe, he talks a lot about unit testing and the test-first strategy. This approach stresses writing automated tests for every bite-sized chunk of program logic. Automated unit testing can more than double the amount of code that needs to be written, but provides a mechanism for detecting when new code breaks old features. And don't you hate when that happens! Ambler also stresses a new concept: what he terms investigative testing. Most of today's testing literature emphasizes testing the specified functionality. Investigative testing takes a different tack: The investigative test team's goal should be to ask, "What could go wrong," and to explore potential scenarios that neither the development team nor business stakeholders may have considered. They're attempting to address the question, "Is this system any good?" and not, "Does this system fulfill the written specification?" A blogger I've been quoting a good bit lately, Jeff Atwood, similarly advises us this week not to limit testing to confirmation of the specifications. His post on Lo-Fi Usability Testing takes off from a book he's recommending to all software designers, Don't Make Me Think, by Steve Krug. His point: the users' agreement that you've met their requirements has very little to do with their ultimate satisfaction with the application. The users, like the programmers, are too close to the project to be the best testers. The best bet is to rope in a few people who know next to nothing about your project. Usability testing doesn't have to be complicated. If you really want to know if what you're building works, ask someone to use it while you watch. If nothing else, grab Joe from accounting, Sue from marketing, grab anyone nearby who isn't directly involved with the project, and have them try it. Don't tell them what to do. Give them a task, and remind them to think out loud while they do it. Then quietly sit back and watch what happens. I can tell you from personal experience that the results are often eye-opening.

Its official!

Last year at the NTC conference in Seattle we met some folks developing some innovative web products right around the corner from us in DC. Over the intervening year we've had countless meetings, IMs, lunches, dinners, brainstormng sessions and afterwork drinks. And today we are announcing a strategic partnership with Orchid Suites. Here's the announcement copied from the Members Only website. February 1, 2007 Washington DC Members Only Software, Inc is pleased to announce that we have entered into a strategic alliance with Orchid Suites Inc., a D.C. based developer of Content-Management and Community-Building Tools. "This alliance enhances Orchid’s ability to deliver best-in-class integrated online management tools for communications." said Tanya Renne, Orchid Suites CEO. The view from the Members Only side of table: this partnership will allow us not only to provide our users with a state-of-the art CMS system, but one that will be closely integrated with the entire suite of Members Only products, allowing an organization to tie its web presence to its basic operational activities. Doria Howe, our Marketing Director, adds "Orchid Suites is more than a traditional CMS - it's a web-suite technology with collaborative tools that are very exciting for Non-Profits. They allow organizations with multiple chapters or interest groups to have integrated sub-sites, while organization staff can easily take control of look, feel and content." The first product to emerge from this partnership, the Orchid Suites - Members Only Link, will make it a snap for our users to give their constituents access to a wide range of Members Only activities on their Orchid-based website, including profile management, event registration and online donations. Orchid is able to do this by supporting the Members Only API, which allows software developers to access a wide range of Members Only functionality from other applications. The Orchid Suites - Members Only Link will debut at NTC 2007, a national conference for non-profit technology to be held in Washington, April 4-7,2007. D.C. For more info visit http://www.nten.org/ntc Learn more about Orchid Suites at http://www.orchidsuites.net Learn more about Members Only Software, Inc at http://www.membersonlysoftware.com If you are coming to the NTC, be sure to see us at the Science Fair!