Corporate tool choice: Why products beat tools every time.

Are you like me at all? Every time I see a "GoTo my PC" or "GoTo Meeting" commercial, I grind my teeth. These "hot new" technologies for Windows have been standard fare on UNIX for over 20 years, and yet UNIX is still viewed as unusable by many corporate types.

As a long-long term computer programmer and tech geek, I had always assumed that the reason that hacker-born tools don't get wide acceptance in corporate environments was because they didn't have salesmen schmoozing the VP into making badly informed policy decisions. This attitude is widespread among my kind, and, well, we're completely wrong.


I have one word for you, Joel: Bootstrapping.


Our geek-myopia is a product of our personal evolution: most of us learned under the wing of someone else. A teacher, guru, or just another geek learned something we thought was cool, and we learned it through conversations and one-on-one teaching..

Life in the dozens-to-hundreds scale

I'll fall back on a simile: the massive success of World of Warcraft. A prior game, Dark Age of Camelot, had better and more scalable PvP, more realistic rendering, and better in-game economics years before WoW even hit alpha testing. Despite that, WoW became an immediate hit. It emptied DAoC's servers almost overnight, with a product that was less "deep" and less stable.

How did they do that?

One difference was a single wart in WoW's graphical environment: the exclamation points hanging over questgiver's heads. They totally "broke the metaphor" of the virtual world, but they gave new users a very good idea where to click first. At that time in DAoC's visual environment, other players, inert NPCs and questgiver NPCs were almost indistinguishable, so there were no cues as to what to do/click first. Chasing after avatars that were players and trying to click on them was both very challenging, and yielded nothing anyway. (Clicking on a player didn't do anything) It was easy to get frustrated.

Further, WoW had extensive beginner quests where the dialogues led the new users through most of the basic parts of the game. The fact was that a new user completely unfamiliar with WoW could become a padawan in a matter of minutes. Not so in DAoC, where things as basic as the "r to reply" key were undocumented and you ended up using "/send blackhawk This conversation interface is really inconvenient" for ages until someone told you about the "reply" key.

If you had been given the task: "Get 80 people in your company to 10th level this Saturday", it would have been nearly hopeless in DAoC, and almost trivial in WoW.

The self-taught path is vital

When you're trying to get a corporation (think dozens or even hundreds of programmers) to use a new tool, there just isn't enough time to chat with all of them and bring them up to speed. A typical tool switch has to be pretty much complete in a week or so. In order to even approach this capability, the product absolutely must have a smooth, bulletproof, and thorough new-user bootstrapping experience. A man page, some screenshots, and an HTML monograph from the designer just aren't good enough to bring 50 people onto a new platform in a week, and that is really what large organizations require. It's not that they want it. They can't actually don't have more resources to throw at the switch and still keep their existing products working.


Many know the expression For want of a nail, the kingdom was lost.

I saw this in perfect detail today as I tried to get started using Eclipse. I saw Eclipse for the first time years ago in version 0.0.0.0.0.0.1 or thereabouts. I knew it was an IDE, I knew it was by-hackers-for-hackers and it was supposed to fill a similar space to Visual-Blarg from Microsoft.

Here's a tick-tock of my experience:

1. I install eclipse with "sudo apt-get install ..." onto my Ubuntu-10 desktop. It nicely adds a "Programming" submenu to "Applications", and places itself in that.
2. I start it up- and wait. For a distressingly long time, actually, before even the splash page appears.
3. It prompts me to pick a workspace directory before it will let me go any farther. This is clunky. It's essentially asking a configuration question before you can even get to the "help" screen to ask what you're doing. By analogy: DAoC used to make you choose the stats for your character before it told you what they did. Both are examples of cart-before-the-noobie processes.
4. It gives me a bigger splash screen with some icons. The upper-left one is marked "Overview". I click on it, which brings up a (very nice) Overview screen with a link "Workbench Basics". I click on that.
5. There is another long-ish pause while the help browser appears in another window. It's long enough that I click on the link a couple more times to make sure I did it right.
6. The help facility window appears, and everything goes to hell. Look at the next three screenshots, as I click on the links:

The "characters are cut off on the left edge" looked to me like bad HTML "div" formatting, so I blew it off and clicked on "Getting Started", then "Basic Tutorial"

Here I waited, and waited, for whatever video or content was supposed to come up next. Nothing. I clicked  backwards and forwards. I even used the (almost invisibly tiny) arrows in the upper right toolbar. The forward (right) arrow did nothing. No error, but no action. Weird that it wouldn't be greyed-out out if it did nothing, so I waited for a media player to pop up or something. Nothing. I tried clicking on the next entry (Concepts) but that obviously took me "too far". Well past the "Basic Tutorial" anyway.

After a long and frustrating series of clicks backward and forward, etc., I gave up and punted: I Googled "Eclipse Basic Tutorial" and found this page at UPenn: Getting Started with Eclipse which includes the useful tidbit:

This opens up and you can click on Basic tutorial, which is a link that opens a page that says "Basic tutorial" and little else.

Then it goes on to talk about "plusses" and clicking on them to open things up. I looked all over the image above for anything resembling a plus... no dice.

Status at this point in time: I'm at a dead stop trying to get to the "Basic Tutorial", with nothing obvious left to try. Even the Google search confirmed my problem but didn't give me a solution.

I assure you that at this point, anyone, anywhere, that is trying to make plans to bring 50 developers to a new platform like Eclipse will mentally up the cost in time and money by a factor of 5-10, which will essentially knock it out of contention.

And it's all because of a stupid help-screen UI issue... a horizontal scrollbar that defaults to a center position:

This seemingly minor glitch has hidden the "magic plus signs" which are the only possible route to the basic tutorial.

There are a variety of things that could be done to solve this:

1. Fix the help utility UI so it doesn't do that by default. Text missing ON THE RIGHT of the screen will get people looking for a scrollbar
2. Rework the minute upper-right scrollbar so that the buttons that do nothing are greyed/stippled and the "Show in Table of Contents" button (which is a hidden back-path to the magic plusses) is among the things people might click
3. Override the scrollbar's initial setting from the command line or environment.
4. Add a "Next Section" link (as occur in almost all of the other help segments) in the "Basic Tutorial" Page.

Items 1 and 2 are the essence of the sorts of things that should be simple, fast, and clean in open source software environments such as produce the help utility.

Items 3 and 4 are completely under Eclipse's control, and would be totally obvious... if the developers had detected the problem in the first place by watching someone new walk through the bootstrap process.

Lessons Learned

If "the good news" was that it wasn't an absence of salespeople, "the bad news" may be just as frustrating: Your bootstrap process is absolutely essential to your adoption in larger environments.

Hitting a hard-stop in your forward progress when you're familiar with a tool and trust it is a completely different thing than hitting a hard-stop trying to find your way to the tutorial. The former will result in a user experimenting, Googling, and chatting their way to a solution. The latter will get hands thrown in the air, and a return to the known-to-work alternative, regardless of how much worse it is.

As a programmer, I know that finding these kinds of things takes easily 20% as much time as is spent creating, testing, and polishing the tools in the first place, maybe even more, and I am loathe to spend that kind of time. But without that time getting spent, the tool might as well not exist as far as larger organizations are concerned.

Just something I noticed.

Terrorism: the macro version of SARS

SARS,or Severe Acute Resperatory Syndrome, was a front and center issue in 2002 and 2003. It killed over 8,000 people worldwide, and received a lot of news coverage. Interestingly, the thing that sets SARS apart from most other diseases, the fact that it killed a disproportionate number of healthy adults, was not something that received a lot of followup. Most diseases affect the young and the elderly in larger numbers than the mid-adult population, SARS bucked that trend.

Without getting into a lot of technical mumbojumbo about pulmonary edema and antibody response, the reason SARS kills more of the healthy population is pretty simple: the virus that causes the illness (SARS-CoV) is ineffective and clumsy. People with suppressed immune systems have survived where healthy people have not. The reason for this is that it is the body's immune response (killing the virus and trying to get rid its waste) that causes the victim's lungs to fill with fluid. The stronger the immune system, the stronger the response, and the more rapidly the victim's lungs fill with fluid. In essence, the more healthy the victim, the faster their life is put in danger. It's the body's own reaction that puts the victim at risk by perverting disease-fighting resources to a self-destructive end.

In conventional war the goal is control. Control requires resources: people, productivity, etc. When fighting a war, one group of resources (governments, industries, populations) allied with one controlling entity try to destroy similar resources which support a rival. For the human race, this is pretty old-hat. Wars are documented in all societies from the stone age forward. Happily, societies with comparable productivity are usually mutually tolerant. Wholly incompatible societies are usually separated widely enough on the resource-and-capability scale that most wars are relatively short. Yes, there are exceptions, but many wars are so brief that they're decided fact before they make the news. It averages out.

Terrorism is quite different. It has two pathologies: intimidation and perversion. Intimidation is the most overt of the two which is why on the surface terrorism seems to fail so blatantly. From the Gunpowder Plot of Guy Fawkes to the 9/11 hijackings of Al Qaeda, the targetted population wasn't swayed in the direction of the attackers. It was completely and strongly against. Seemingly, terrorism had failed.

That, unfortunately, is only half of the story. Like SARS, terrorism's main damage is dealt by perverting normally healthy responses to destructive ends. Terrorist attacks can redirect a huge amount of resource toward ends which benefit the country virtually nothing, stunting its normal growth. On the order of a trillion dollars have already been spent by the United States trying to prevent additional plane-related attacks. In all likelihood, virtually every dollar was wasted. The other reaction: waging war upon Afghanistan, exerted sufficient control in the area that any similar hijacking plans which may have been in the offing were completely distrupted. Beyond that, the TSA, the DHS, etc., were merely public-facing efforts to put people at ease, and today represent billions in misspent resources.

Imagine for a moment the alternative history where reaction to the hijackings is delayed for a year: Al Qaeda kills 3,000 people on 9/11. The next day, everyone goes straight back to work and continues on. There are 3,000 less workers today, and there is some societal capability lost, but the other 339,997,000 Americans go back to work. On 9/12, Al Qaeda sacrifices another 20 of its zealots and kills another 3,000 americans. Rinse and repeat for one year. This assumes that Al Qaeda could field and fund over 7,000 suicidal zealots and find 365 locales densely populated enough to kill 3,000 people every day. In the course of this "year at war",the United States would have lost less than one third of one percent of its population. Finally the United States launches a war in Afghanistan, removes the support Al Qaeda was receiving, and then goes back to normal operations. In the past 10 years, that United States would have had a trillion government dollars to spend on health care, spaceflight, and fighting off the mortage crisis; in short on everything else the United States does.

Nineteen hijackers in exchange for three thousand dead Americans and "a woken, angry giant" is a lousy trade. Nineteen hijackers in exchange for removing $100 billion per year from the US economy could be considered quite a coup. Perhaps, as the 10th anniversary of these attacks approaches, we should consider rethinking our priorities.

Widely separated dots: Skills in parenting and computer usage

In foggy memory of a college course in sociology I took many years ago, I remember hearing about a study where a parent and their kindergarden-age child were paired off and given a pile of toy automobiles. Half of the toys were red and half were blue. Half were trucks, and half were cars, with each combination being about 1/4 of the vehicles. The task was to separate the toys into piles with common attributes, but only the child could touch the toys. It wasn't specified how the toys should be divided.

A pattern that emerged was that one group of parents tended to accomplish the task by making the child an extension of themselves:  "Take that truck, put it in the pile over there", lots of pointing and direct instruction. A different group of parents tended to explain the goal to a greater degree, and let the child act on their own: "Put the red toys in one pile and the blue toys in another". The groupings seemed to correlate with all sorts of interesting things: education level, income, wealth, etc. I seem to remember thinking that maybe they had cause/effect backwards: that perhaps a tendency for direction vs delegation could drive the parents' ability to learn, earn, and conserve wealth. Unfortunately the groupthink of coordinated nodding got to me, and I didn't raise the issue.

Many years later, I was working with a talented friend at a software company. He and I were each project lead on two separate but related projects. He was an OO evangelist, to which I had not yet been assimilated, but have since adopted. In short, he was a very smart guy whose opinion I did (and still do) respect. Another difference between us was that he absolutely loved Microsoft Windows. I loathed it, preferring a UNIX command line. We had long since agreed to a friendly disagreement.

One day, we were working on a common chunk of code in his office. He demonstrated a test run, which consisted of going to the database window and creating a fresh database, going to a filesystem window, selecting a range of output files and deleting them, going to the system profiler window and clearing the cache, and lastly going to the application window, and (with a mere 6 more clicks or so) starting the app, which ran to completion and generated the desired data. He spoke at some length about how easy all this was, compared to the days he'd had to use UNIX for programming. (his college days) Just point, click, and it all worked! (If I were accurately reflecting his tone, I'd've used three exclamation points there) I asked him to come to my office and see me do the same thing, and he agreed. We got to my command prompt, I typed "runtest", and the script did everything that four window selection and dozens of clicks had done, only it was less error prone and faster.

He wasn't swayed, and his objection stays with me: "But you had to write that script!". He was eminently satisfied with a system that required his presence and direction. He wanted a tool:, I wanted an assistant, and  was willing to take the time to train one (write the script). He really didn't want to waste time writing scripts, feeling that the goals changed often enough that you ended up spending more time writing than you saved by using them.

Two years ago I got a chance to follow up on that. At an offsite programmers' lunch for a  different software company, I asked: "What is your computer doing for our company right now while you are at lunch?" Some folks said "Compilling", some said "Building datasets", others "Planning a new rack layout", etc. But by far the most said "nothing". Both groups were mystified that the other group was so big.

Hegl long ago separated "self" from "other", and I don't know if there's an official separation of "other" into "tool" and "agent". In the sociologic test, some parents were employing their kids as tools to accomplish the task, while others were using them as agents. It might be interesting to poll people who have become successful in various fields and ask them about how they think their parents might've approached the original test