Change Bitterness and Accidents of History

Jun 17, 2016, 3:16 PM

Tags: domino

It's pretty easy to see that change is in the air for Domino types. It's been taking a number of forms for a while now - the long delay since the release of 9.0.1 and associated aging of the tools and infrastructure have led to a series of forced adaptations for developers and administrators. Developers, for example, have had to keep light on their feet to adapt to new browsers and devices that the framework doesn't automatically support, as well as a shift toward manually including jQuery and other tools that have a bit more wind at their back than Dojo. Administrators, for their part, have had a series of heart attacks related to SSL and other security matters, usually involving a a lot of noise followed by (unfortunately, I feel) a good-enough patch from IBM.

That sort of thing isn't likely to get any smoother. In large part, that's entirely distinct from anything IBM does: the genie's out of the bottle when it comes to fast-moving platforms, and the best we can hope for is a sort of still-moving linga franca that can be sort-of-stable on the majority of targets. But then part of that is Domino: for all its virtues, it hasn't adapted for the modern world, no matter how much some of us would have liked it to. And that's had some negative side effects on us as a customer base, side effects that manifest as a gut-reaction rejection of the modern ways of doing things.

Take the SSL thing, one of my soap boxes: though the immediate problem could be summarized as "IBM should update their SSL stack", the larger issue it exposed was that our beloved monolith is mortally vulnerable to a single component falling behind. And, in fact, it made clear that we're spoiled by the approach: many of the reactions were basically that we shouldn't have to worry about things like reverse proxies or the general notion of distinct systems for web front-ends and the app server. And that initial rejection of the hassle has implications, limiting the average Domino installation's capacity to scale for load balancing or failover in a smooth way, things that come almost "for free" with a reverse-proxied setup common among almost all other app servers.

Developers have it worse: the "power user turned developer" history of Notes and the particular peculiarities of the platform* have left us desperately behind the baseline for modern development. The tooling has coddled us into preferring inline scripts and procedural programming to structured code organization, into viewing a thoroughly-staid language like Java as something outrageously complex, of only begrudgingly adopting SCM due to the platform-induced hassle, and of almost entirely ignoring automated testing. And similarly to the SSL discussion, the historic "one tool for every job" nature of Domino leads to natural pushback when faced with other platforms.

And I get why! And I feel it too. It's a real PITA to now always have to be on the lookout for some new point release of iOS or Android to break drop-down boxes or something, as opposed to years of deploying Notes apps that looked and worked identially across every version forever (pretty much). It's also a drag to run into situations where the problem is "easy" on Domino but more cumbersome elsewhere, like platforms that farm out their FT indexes to distinct servers, or don't include document/record-based security. That makes it very easy to become blinded to the tradeoffs, though. It may be nice that Domino is a one-stop-shop for so much, but it's a shop that requires Designer, that makes it very difficult to use third-party-dependency systems like Maven (even within Maven projects), that lags in DB features found elsewhere, that is only awkwardly accessible from other app-dev frameworks, that has an API that's a bit older than Windows Me, and that essentially never showed up for the modern development conversation.

Domino has always had a lot to recommend it, and XPages has carried us very far. And hey, this is enterprise software - even if there's never a major new version, there'll be paying work forever. It just may not be the kind of work you want to do, and it is almost definitely not truly healthy for the companies paying for it. So what I recommend is that you have a plan. The good news is that there are a great many next steps that build smoothly on existing Domino knowledge and, potentially, infrastructure. Certainly, I'm thoroughly biased in the direction of Darwino, but that's one of many. You could also do worse than learning a mature platform like Ruby on Rails (heck, you could run that on JRuby on Tomcat or WebSphere). Take some time to learn about reverse proxies and modern web-server setups. Basically: something. Just do it with an open mind, and don't balk at the first thing that's more complicated than the Domino equivalent. I think a bit of that will serve you very well.

* And, to be fair, of the overly-conservative nature of enterprise programming.

Other than, of course, being one of the progenitor NoSQL databases.

Commenter Photo

Andrew Magerman - Jun 18, 2016, 6:45 AM


Must agree with you.

It's a shame that IBM did not do more in the direction of 'conscious decoupling' to allow us to add modern technologies to the base. The only exception I can think of is giving a REST interface for data, which was great. The way the on-disk projects are saved, with timestamps, makes a clean source version control with git a PITA, the old jvm (I long for Java 8 I do), the abscence of JUnit natively - it seems to me that with a modest investment one could prolong the life of Domino infrastructures.

One major goodie from the classic Notes development was the 'everything in one nsf' concept which made deployment a doddle. That I miss in modern development environments, where dependency management has become one of the key skills.

All the best from Switzerland


Commenter Photo

Gavin Bollard - Jun 20, 2016, 2:28 AM

While I agree that IBM hasn't been looking after Domino so well in recent years, I still believe that the platform has a lot to offer... at least until the surrounding platforms mature. 

I too was really annoyed at the way IBM handled the SSL thing but at the same time, I recognise that the age of the administrator is effectively over.  This sort of thing wouldn't happen on a cloud platform. In fact, it's one of the top reasons to migrate to the cloud... .so that you can concentrate on the data and the processes while ignoring the infrastructure. 

From a development point of view, IBM weren't the only ones making a complete mess of things. Sure, tampering with the classic NSF has made things overly complicated but at least you can still build web-enabled (and modern) apps on domino (using bootstrap) without having to venture into XPages territory.  Look at what Microsoft did to Visual BASIC. Theirs is a  better lesson in how to kill a product. 

I'm enthusiastic about IBM Connections. It's got a long way to go but it certainly replaces some of our Notes features.  Our plan in the short term is to find a way to trust the connections login and have users seamlessly wander between our extranet and connections. After all, there's still so many things that Notes/Domino can do that connections simply can't.  

That's short term. Long term, we're looking at Bluemix to see what IBM provides in terms of Rapid Application Development -- and of course, we're keeping tabs on how well it integrates with Connections. 

Commenter Photo

Ben Dubuc - Jun 20, 2016, 11:44 AM

Just a thought...   Why doesn't IBM give back Notes/Domino to some new "Iris"?  Not that I don't like what IBM did with Domino the past few years, but if IBM's intents are to just maintain the platform, why not look if you can sell it to someone who'd like to make it evolve even more and follow a bit closer on what's happening in the IT world.

After all, companies are / will find it hard to get rid of Domino, so why not make the move while you can still create some interest in the platform from the many companies that want to get rid of Domino, but still have to keep it, as moving apps to other platforms would represent a huge cost?  For the past few years, I have been working in such companies, where they want to get rid of Notes but the amount of work required to convert the apps to other things (SharePoint, .Net, whatever...) is just too big.  In my area, this kind of work represents about 90% of what is available.  So I'm stuck doing maintenance for apps that have been developed almost 15 years ago.  the problem is that they still work, are used a lot, and some are highly complex, consuming and providing web services, that it is clear in my mind the company will need to keep a few Domino servers alive.

If I knew that Domino had a few cool things to come, I could go and try to convince my boss that instead of moving apps to other platforms, I could revamp a bunch of them quickly by moving them to XPages and Bootstrap.  But now, after a few posts like this one, after what has been said at the Connections conference in Toronto a few weeks back, how can I convince my boss to invest in a platform that is not going anywhere?  Sure Xpages would be a nice upgrade, but is it worth it?  Why not invest a bit more than and move everything to SharePoint / .Net???

I  know I already registered for some C# classes, just in case...  I still know my way around Java and a few other languages, but I guess it's time to move along...  for real, this time.  I tried to get away from Domino, but we are such a rare breed here that I kept getting called backed to it.  But this time, I have a feeling it's really the end...  Unless I want to do maintenance, but that's not quite what I'm looking for in my daily work.

There is a fair amount of sadness in all this.  The platform does have a lot of advantages (heck, I laugh when they roll out an update to the SharePoint Intranet  and it takes the whole weekend), but it really needs to be able to evolve, and the customers need to know there is a commitment to making the platform evolve and follow the rest of the IT planet.  Right now, we get the exact opposite message...

New Comment