IBM Lotus Workplace: The PL/1 Of Collaboration

I attended a two-day seminar at IBM in Waltham, MA last week, on "IBM Lotus Workplace Application Development". I've been delaying posting about it publicly, but since John Head has posted his day 1 and day 2 notes from a version of the seminar held in his area this week, I've decided to at least post an overall impression.

I happened, by the way, to be in the same class as Bob Balaban of Looseleaf Software and 3CInterop, as well as Ken Yee of Key Solutions and Notes FAQ and Java Servlet FAQ fame. One of the high points of the class came during the lab exercise in which we were to implement an Instant Messaging logging facility. Well, "implement" is actually too strong a word for that lab, since the code was all pre-written. We were simply supposed to build and configure it. But as soon as I looked at the code, I said "That can't be right!", and pointed to a loop whose only purpose seemed to be to read a character at a time from the input and perform a logical And operation against the value 255. Ken took a closer look and pointed out that the input consisted of byte values, and they were being processed as ints, so the And operation was masking out automatic sign extension. I then pointed out that the input stream ought to be Unicode, so whatever they were doing, it was asking for trouble. A quick test copying some characters with diacritcs from the Windows Character Map applet into the IM window proved that the code was losing data. Bob knows at least as much about character sets as I do (and I specialized in software localization at Wang for a few years in the mid '80s, so I used to really live and breathe this stuff!), and he quickly pointed out that the loop and integer conversions could be completely removed from the code if we'd simply tell some of the Java methods that they were getting UTF-8 as input. Ken and I entered in the fix on our respective lab machines, recompiled the code and tested it again. Needless to say, it worked perfectly.

Now, back to the main point of this post...

This was the closest, most in-depth, look that I've had at the IBM Lotus Workplace products, which are the J2EE-based products that IBM has been talking about for several years now. I am a Lotus Domino guy, a "tree-hugger" in some IBMer's parlance, but I'm not one of those people who believes that IBM is actively trying to kill off Domino and force customers to rip-and-replace their infrastructures. Ed and others have thoroughly disabused me of any possibility of that. The instructors for the seminar made it perfectly clear, too, and so did the class itself, because it proved beyond any shadow of a doubt that the new product lines aren't anywhere near capable of duplicating the RAD and rich custom collaboration features of Domino.

So, what's with this allusion to PL/1 in the title of this post? PL/1 is a dinosaur programming language, and Workplace is a thoroughly modern suite of collaboration products. What could they possibly have in common? Well, PL/1 was designed by committee. Workplace may or may not have been designed by committee, I can't really say, but it has a certain attribute that makes it look like it was: duplication. Legend has it that the committee that designed PL/1 had three factions. There was the "we're designing the next COBOL" faction, the "we're designing the next FORTRAN" faction, and the "we're designing the next ALGOL" faction. Evidence in the PL/1 language tends to back up this legend. One can point to various elements of the language and easily identify which faction wanted it to be put in, and there is an awful lot of overlap. Any given program can, of course, be written in many ways and many styles in any programming language, but in PL/1 you have an even wider array of choices because you can write your code using COBOL-like features, using FORTRAN-like features, or ALGOL-like features. Although, over time, PL/1 became a pretty good language and the compilers for it also got to be very good, it has never overcome its early reputation of being bloated, slow, and difficult to work with. My experience in this Workplace class leaves me wondering whether IBM, which was the parent of PL/1 by the way, is creating a product that is going to be saddled with the same reputation, so that no matter how good it gets -- and it will get good -- people will always think of it as it is now: bloated, slow, and hard to work with.

There are some really, really good ideas in Lotus Workplace. There's no question about that. I was thinking about what Lotus executives were calling "contextual collaboration" about a year before they started talking about it, and the idea of a component-based collaboration framework is something that I really believe will have tremendous benefits. Unfortuately, the J2EE and portal superstructures upon which Workplace was built give it so much overhead that the description I gave above fits. It took ages to boot up the 2.2 MHz/2 GB lab machine on which we ran our servers. Page transitions were slow. Painfully so, in some cases. To IBM's credit, this is not a realistic production environment, but it should have at least been tolerable as a test environment. Also to IBM's credit, none of the servers crashed, but browser restarts were necessary on several occasions because caching issues that could not be cleared caused some of our lab assignments to fail. This will all get better. I'm quite certain of it. What I'm not so certain of, however, is whether application development for Workplace will get better. What I saw primarily in class was a wide variety of techniques for doing the same thing. There must be eight or ten different paths you can go down to expose a Domino application to Workplace users, and none of the paths that are fully baked at the moment seem to offer any significant advantage over the others. I get the feeling that the very open-ness of the Workplace architecture is working against IBM in this respect, because different groups within the company (as well as some 3rd party vendors) are all taking advantage of the ability to plug in new components, which is good, but they are pursuing similar goals in different ways and what they will end up with is too many choices for application developers.

From a Domino tree-huggers perspective, I should point out that I am happy to see IBM put such an emphasis on exposing Domino data to Workplace users. The native Workplace development tools, as they are today, have nothing to compare with the simplicity of basic Domino development. You can, of course, take more direct control of the UI generation in the native Workplace environment, and the portlet model offers definite benefits, but at the same time it's a bit constraining as well. When applications are pieced together out of components, they can be remarkably consistent... but that can end up meaning that they are consistent in non-innovative and boring ways -- for users and developers. Workplace will eventually have some RAD development tools. We should see a forms-based application development tool in Workplace 2.5. (The instructors in class emphasized that it is available now, but only as a "technology preview".) Whether that 2.5 tool will even have the power to duplicate something as simple as the Recipe Database in the old Lotus "Nifty Fifty" remains to be seen. Meanwhile, I'll probably continue to hug trees for a while longer, but I'll keep my finger a little closer to the pulse of Workplace, probably seeing a few more sessions on it at this year's Lotusphere than last year.