IBM

As of today, June 27th, I am no longer working for IBM.  Last quarter’s widely-reported “resource actions” (lay-offs) hit my group and this time my number came up.

It was a good run, 27 years with one company, something that is not so common today.

Fresh out of Harvard I started working at Lotus Development Corporation in Cambridge, Massachusetts, initially doing technical support, including for the Lotus 1‑2-3 C-language developer toolkit.  From there I worked in support’s application development team, developing and maintaining our internal information retrieval system, a hodgepodge of a DOS user-interface, a search engine (using a Bayesian inference network) and a fax-on-demand system, all over NetBIOS.

From support I transitioned over to development, to the SmartSuite team, where I first focused on Freelance Graphics, which was transitioning from C to C++, Windows and OS/2, then on a set of Windows ActiveX controls called eSuite DevPack, some Java components and attempts at an office suite running on a Java-based “thin client” or network computer (eSuite Workplace.)  It was a time when the thinking, at least in my little part of the world, was that the traditional desktop applications were dead, and all future work would be done in Java running on your desktop web browser. From this came the browser wars.

Then, in 1995, IBM came a knocking and bought Lotus.  Our focus, naturally, shifted from desktop to server-based computing, from Java applets to Java servlets.  I worked on various projects, from the K-Station Portal (based initially on Domino) to the Apache Xalan XSLT engine to XForms to WebSphere Portal.  I developed a framework for document conversions within WebSphere Portal that we called Document Conversion Services (DCS).

Then, one day, I got an odd call, out of the blue, a very senior person asking whether I was familiar with the file formats from SmartSuite and Microsoft Office.  Evidently, no one else in the company would admit to having that arcane knowledge.  So, I was drafted onto a “special project,” with a few other talented engineers, a real fun group working on various stealthy tasks, the details of which I am still not at liberty to discuss.

Somewhat overlapping the above, I worked on the things that readers of this blog will be more familiar with, the development of the OpenDocument Format (ODF) standard at OASIS and ISO, and the arguments against ISO ratification of Microsoft’s Office Open XML (OOXML) file format.  This then overlapped, in part, with my work to establish the OpenOffice project at Apache, based on Oracle’s contribution, to get IBM Symphony contributed as well, and to bring those two efforts together.

Those years were among the most memorable of my career.  I was able to work with a lot of talented and enthusiastic people, within IBM, of course, but also at other companies, with non-profits, with academia and government.  I was able travel and see parts of the world I might never have otherwise seen, speak to a lot of audiences about the importance of open standards.  I even testified to a few legislative committees.  My business travels took me to Brussels, Berlin, Budapest, Barcelona, Granada, London, Paris, Lyon, Rome, Orvietto, Geneva, Amsterdam, the Hague, Beijing, Seoul and Johannesburg.  It was a lot of hard work, but it was meaningful. Open standards and open source matter.  I have many fond memories of those years.

Eventually, however, corporate interest in document editors, document standards, “social documents” and similar initiatives fizzled, and I no longer had support for remaining involved in ODF and OpenOffice.  I needed to move on, to find a new gig.

I looked internally within IBM for something that would combine my hard technical skills and my soft skills, including working closely with attorneys, an ability to “meet them half way” when discussing complicated legal/technical topics.  Since I’ve been an active inventor throughout my IBM career, with 54 patents to my name, and a good head for reading and analyzing patents, I spent a few years working as a patent engineer, helping to monetize IBM’s vast patent portfolio, developing technical evidence for infringement, identifying possibilities for patent licencing and assignment, etc.

That’s where things stood as of today, when I handed in my badge and laptop.

As for what is next, I honestly cannot yet say what “Rob 2.0” will be.  I plan on taking some time to mull things over and explore my options.

One thing I do plan to do, relatively soon, is start a new blog, a fresh start, on a new path at this domain, preserving this older blog at its current (/blog) URL.

I’ve been reading a lot of interesting discussions about the amazing Jeopardy match between human champions and IBM’s Watson computer.  Although I’m in no way involved in this project, it is very exciting to watch this event unfold.  Some of the discussions I’ve read concern the impact of reaction time, who can get to the buzzer fastest.  I recommend this analysis of how the buzzers in Jeopardy work, which explains what Watson does and what the best human players do.

But I’d ask you to try this thought experiment to see how reaction time really doesn’t matter in the larger sense.

First, let’s imagine a trivial version of Jeopardy, where the categories are “Multiplication tables up to 12×12” and similar.  Questions so easy (for average adults) that winning or losing is pretty much 100% determined by skill and timing with the buzzer.  This would not be a very interesting computing challenge.

But then let’s imagine playing something like Jeopardy, but where the questions are 10x more difficult.  So have questions that are more obscure, require more calculation, greater recall, in general more significant thinking.  In this case, no one is jumping to the buzzer, because everyone is digging deep for the answer.   Essentially, take reaction time is taken out of the equation.

Some examples:

• “The first African contestants in the modern Olympic Games represented this African republic”
• “According to the Book of Genesis, he was the father of Mathusael”
• “This George I’s 2nd wife was Euphemia of Kuyavia”
• “In Shakespeare’s A Midsummer Night’s Dream, he was the Master of Revels”

Get the idea?  Ratchet up the difficulty level.

Who wins now?

I think in that case, Watson would be the clear winner.  This plays to the machine’s strength’s, based on its ability to process huge amounts of data, far more and far faster than any human.

The underlying technology of Watson is not best used to give instant answers to liberal arts questions that would be covered in any freshman survey course on European history, or classical music.    Those topics are used only because Jeopardy is targeted for mainstream television and needs questions of limited difficulty, sufficient to make it an exciting game for humans to play and watch.   Sure, Jeopardy is more difficult than other U.S. game shows (but not as difficult as some British quiz shows), but it is still “human-scaled”.  In essence, questions on Jeopardy are “dumbed-down” to match human capabilities and the format of the show. That is why I’m so excited about the future, not entertainment uses of this technology, but uses that attack and solve much harder problems, problems with greater impact in fields like medical diagnosis, law enforcement, etc.

The real excitement is not what we can do on TV game show,  but how we can scale up this technology to change the world.

BTW, if you are wondering, here are the answers to the above questions:

• What is the Orange Free State?
• Who was Mehujael?
• Who was George I, King of Galacia-Volhynia?
• Who is Philostrate?

We (IBM’s Software Group) are doing a survey of user perceptions of the “consumability” of our products.  “What is consumability?” you might well ask.  It is a new word for an old idea.  It describes the end-to-end customer experience, the consistency and cohesion of our products and solutions, from acquisition, prototyping, through integration, deployment, maintenance and upgrade.  The idea is ancient.  Vitruvius, in De Architectura wrote of Firmess, Commodity and Delight (firmitas, utilitas and venustas) as the ideals of a building.  Commodity here used in the sense of commodius or serviceable, convenient, well-adapted to its purpose, etc.  I think that “consumability” is the modern buzzword for that ancient architectural virtue.

But I digress.

If you use IBM products, and can spare 20-30 minutes to take an online survey you first-hand experiences with software consumability, then I encourage you to head over to this page, and share your thoughts.  The survey is available in 10 languages (English, Brazilian Portuguese, Simplified Chinese, Traditional Chinese, Korean, Japanese, German, Spanish, French, and Italian).

I’m told that earlier forms of this survey resulted in 1400 product suggestions, 900 of which are reflected in currently shipping products.  So this is good way to get your opinion heard and acted on.

Thanks!