Tip of the Iceberg

Category domino rants
I've hinted at this before, both here and elsewhere, but I think it's time I finally just came out and said it: I suspect that, to IBM, Domino developers are an afterthought. I'll make my case for that in a moment, but first, a disclaimer: typically, nobody likes to be wrong. In this case, I hope I am. I'd like nothing better than to not just be reassured that I'm wrong, but proven wrong. Demonstrably. And soon.

Try something for me: open up Domino Administrator 8. Assuming you haven't clicked the "Don't show this again" checkbox, you'll see a bright, shiny, new Welcome Page that's been spruced up a bit for version 8. Okay, now open Domino Designer. As you might expect, a Welcome Page that's been... wait, did I click the wrong shortcut? I wanted to open version 8, not version 6. Never fear, you're in the right place... IBM just forgot to update the Designer Welcome Page when they were rebranding everything else. Again. I wouldn't really care - that's not where I spend my time - but it's emblematic of a recurring theme. Like the Welcome Page, most of the Designer client has not changed much since 1999.

Mary Beth Raven's blog has arguably done more recently to involve the community in what Notes is becoming than most resources IBM has allocated to that purpose. One exercise that she's described in great detail is the creation of "personas": fictional customer identities mapped to a very granular level to help the product designers better relate to the very individuals for which they are designing the product. The end user personas formed one basis for many design decisions for the interface of Notes 8. As development progresses on the next release, MBR has now also described multiple administrator personas, constructed to allow the same mindset that was applied to giving "Samantha" a powerful, beautiful, and usable interface to produce the same for those that support the product day in and day out. Roughly six weeks ago, we were assured that developer personas are in the works as well... but only after I complained that it seemed developers had been forgotten. Naturally, I'm not implying that they decided to create developer personas specifically because I whined... I'm just pointing out that we weren't told about them until then.

I could dredge up a myriad of other symptomatic examples. I wouldn't go so far as to say that developers are taken for granted, much less completely forgotten, but I do genuinely feel that they're an afterthought. Obviously there's a need to address the actual end user experience. But let's face it: if you deploy Notes and Domino, and don't have access to development resources (be they permanent staff, contractors, consultants or business partners), all you get is PIM. Oh, and discussion databases. Wouldn't want to forget about those, of course. Add Quickr on top, and you get a bit more - blogs, wikis, etc. But that isn't what ultimately addicts Notes shops to Notes. It's the custom apps. It's the capability of the platform to mold itself to the way your business functions by streamlining processes as varied as purchase requisitioning and equipment calibration oversight. It's the way in which a developer can provide that functionality rapidly, often singlehandedly, and - surprisingly often - with no formal training, education or even programming background. That is why most companies that love Notes love it, and why even companies that claim to (and wery well may) hate it keep it: because they know there's nothing else out there that can do what it does as well as Notes does.

Granted, many an end user or executive that has fallen in love with one or more custom Notes applications has nonetheless repeatedly begged their I.T. department to "get rid of Notes" just because of pet peeves with the mail and/or calendar interface, not realizing (or, in some cases, not caring) that if they actually did abandon the entire platform, they'd lose the applications they do like as well. So I'm very glad to see the ammunition that Notes 8 brings to that battle. But the reality remains that many companies that have long fought the temptation to bail on the platform would have given in long since were it not for how dependent they are upon the applications - and accompanying ROI - their developers have provided them. Despite the many flaws in Outlook and Exchange, I have yet to come into direct contact with an organization that has considered migrating a "PIM-only" Domino infrastructure to Exchange but later reconsidered strictly because of Domino's superiority in that featureset. I've encountered plenty who actually tried to migrate away and gave up when they realized they'd be blowing millions in a futile attempt to reconstruct their existing application architecture within an inferior alternative platform.

And now, with composite applications in Notes 8, we've been given the opportunity to create even more compelling solutions for Notes users. But... have you tried to yet? Or even found intelligible documentation? Hamlet said, "I could be bounded in a nutshell and count myself the king of infinite space." Apparently he was learning Java. If a 1254 page book is a nutshell, then Java is a coconut. Like, a state-fair-winning coconut. Bigger than your head... and therein lies the problem. To really take advantage of where Notes is now headed, you must grok Java. Not just well enough to create a direct procedural equivalent to what you might write in LotusScript using the Domino classes; you actually have to grasp the underlying structure of the language, know its pitfalls and how to avoid them as well as its strengths and how to leverage them, and be familiar with all the layers of complexity to the point that it doesn't slow you down. For most of us, I suspect that will be our biggest challenge in 2008. And I fear many will simply be left behind (with luck and a lot of extracurricular investment, I won't end up in that position myself).

One of the easiest ways to rapidly become comfortable with a language is to work inside an IDE that nurtures your exploration. Even something as basic as typeahead ends up not only saving time, but also reminding the developer of an object's API without forcing them to continually Alt+Tab between their code and the language documentation. You know what IDE is great at that? Eclipse. The very framework that provides the underlying basis for RCP, which is the basis for Expeditor, which in turn now forms the basis for Notes 8. But not Designer. That's on the horizon (although behind which windmill, we haven't yet been told... well, okay, some of us have). Understanding that I'm entirely biased, I feel it should have been the reverse. In fact, porting Designer to Eclipse should have begun the moment they decided to add Java support to Designer.

The irony is that Eclipse is, first and foremost, an IDE. So to create RCP, they actually had to strip out all of the IDE-ish features of it, leaving behind only the interface components and underlying plugin architecture. So instead of taking the IDE, which has from day one provided stellar support for coding in Java, and simply adding support for LotusScript, Formula, and the visual aspects of Domino development, they first stripped Eclipse bare of the development-related layers and then dropped the Notes client on top of it. And, as we've all seen, they did a heck of a job. But those of us tasked with keeping customers in love - and "seducing" new ones - with everything about Notes besides its PIM functionality have to wait, continuing to use a development tool that hasn't significantly evolved since... well, since the last century. That's an overly melodramatic choice of terms, but it's still been eight years. I'm eagerly awaiting the next evolution of Designer, and hoping against hope that, as the complexity of Notes and Domino development increases, IBM proves me wrong with:

• tools that shield the average developer from a reasonable portion of that complexity
• documentation that is abundant, easy to find and understand, and rapidly gets us up to speed on new ways to keep customers in love with the platform
• and any other forms of developer support they choose to provide that demonstrate that they really do realize what's at stake if developers feel neglected.