There’s a major problem that is growing increasingly critical in the Mumps application world: where are the new generation of developers going to come from to support what is a pretty massive legacy of applications? The US Dept of Veterans’ Affairs’ (VA) VistA Electronic Healthcare Record (EHR) is just one of a large number of healthcare applications that was written in Mumps and is supported and maintained by a dwindling number of developers who understand and/or enjoy using Mumps. The sheer scale of VistA and its growing popularity as an Open Source EHR outside the VA means severe problems ahead if a way of injecting new blood into its development community cannot be figured out very soon.
Simultaneously, there’s always been a massive frustration amongst those who (like me) have “gotten” Mumps: nobody else in the IT industry has ever been able to “get it” at all.
Sadly, that magic became increasingly hidden underneath deficiencies that the wider IT industry have progressively picked upon in Mumps, for example:
- an old-fashioned, unfashionable and limited language
- legacy code that turns being arcane into an art-form and lacks any semblance of the kind of variable scoping that all modern developers would expect to see
- a database that was seen as just plain weird, particularly during the 80s and 90s when RDBMS reigned supreme
I’ve covered many of the reasons for these perceived deficiencies in an earlier blog article, but understanding the reasons isn’t sufficient to encourage todays’ generation of developers to do anything other than avoid Mumps like the plague (pardon the pun). If I’m honest, I’m sure if I was a few years younger and came across Mumps for the first time, I’d feel exactly the same too: learning Mumps wouldn’t seem like a terribly smart career move.
Of course, if we’d been able to convincingly articulate just what it was that made Mumps special to the wider IT community, then we wouldn’t have a problem: young developers would be lining up to learn and use it, particularly at a time when jobs are in short supply and their generation are desperately seeking worthwhile purpose: what could be more worthwhile that applying your IT skills to healthcare instead of the frippery and superficiality of gaming and/or social media? Instead, despite its worthiness, they give Mumps, and therefore healthcare, a wide berth. Recent experiments by OSEHRA to train a new generation of Mumps developers have demonstrated zero retention rate from around 200 students. The bottom line is that it’s a dead language.
There’s plenty who will say that the death of Mumps has been being predicted for as long as it’s been around and yet here we are, 30 years later, and it’s still there, alive and kicking. Perhaps so, but the small number of new developers who join the Mumps development community is greatly exceeded by the number of existing Mumps developers who are leaving through retirement or, sadly, passing away, and it won’t be long before the situation genuinely becomes critical.
It’s fair to say that there have been lots of attempts in the past to remedy this situation, none of which have had anything other than a minor impact.
In the mid-to-late 1990s, InterSystems morphed their portfolio of acquired Mumps products into an object-oriented (OO) technology: Caché. Whilst undoubtedly a commercially sensible and successful move for them, nevertheless it remains a comparatively little-known, niche product, certainly by comparison with the household names of Oracle, SQL Server, MySQL and the many new, well-known NoSQL databases such as MongoDB. Furthermore, many of us saw a discontinuity between layering a formally-pre-defined class based object layer on top of the free-form, dynamic hierarchical database that sits inside every Mumps and Caché system. It seemed to me that one of the best and most powerful features of the technology was being wasted and compromised by such an OO implementation. If that wasn’t enough, anyone wanting to use Caché’s object database has to learn a special language: Caché ObjectScript. This is essentially the Mumps language with some (in my opinion very ugly) additional syntax to provide it with its OO capabilities. Adding such object capabilities has clearly not been enough to attract the attention of modern developers and let them forgive the other deficiencies of the underlying Mumps language. Mind you, Caché not being an Open Source product hasn’t exactly helped either. Anyway, the not insignificant technical and marketing efforts of InterSystems have failed to impress the new generation of developers: few I meet have even heard of Caché.
There is also no shortage of language bindings for Mumps: over the years, pretty much every modern language you can think of has had a binding of some sort created for it, allowing globals to be manipulated and routines to be invoked from that language. Bringing globals and the portfolio of legacy code to practitioners of those languages has clearly been ineffective: the magic “je ne sais quoi” that I and others know to be there in Mumps clearly hasn’t been apparent to those practitioners despite these bindings making it available to them.
We’ve even had complete conversion tools, one of the more recent ones being a product that could convert legacy Mumps code to Java, and move the database to a relational database such as Oracle. That has failed to create any impact either.
Meanwhile, I’ve developed numerous Open Source projects and made umpteen presentations to the wider IT community, showing off the NoSQL capabilities of the Mumps database. Instead of being impressed that a Mumps database can behave simultaneously like BigTable, Neo4j and MongoDB and therefore worthy of further inspection, the usual reaction has been along the lines of “but I can already use BigTable, Neo4j or MongoDB if I want those behaviours”. The fact that we’ve been able to do the equivalent thing for 3 decades with Mumps is a mere half-interesting piece of history as far as they are concerned.
I’ve seen two main camps emerge from this:
- a hard-core of Mumps developers who are still convinced that, despite the odds and evidence to the contrary, it really is just a case of training lots of new students and that magic ingredient in Mumps will light a spark in them too: they believe that newbies just haven’t “got it” yet, and they believe there’s just not been enough publicity and marketing applied to the problem;
- the majority (which includes the wider IT community who might just have heard of Mumps) who have concluded that it’s a lost cause and that the day has come to just put a bullet in the dying beast’s head and put it out of its misery. Of course the unanswered question is: what you do with the man-centuries of legacy code that is running a large percentage of healthcare worldwide if you adopt this strategy?
All rather depressing, you’d therefore think, but before you, too, give up the cause, let me bring a glimmer of hope.
I now believe there’s a third way ahead, and it offers real potential. It’s the result of some thinking, research and work I’ve been doing over the Christmas period and is the reason why I’ve been quiet in this blog for a while. I’m now really excited about it. I announced it at the WorldVistA Community Meeting in Sacramento last week and even had it being excitedly used and tested out by those who attended my EWD training class in the days before that meeting.
The thing that particularly excites me is that as a result of this work, I’ve finally been able to put my finger on exactly what it is in Mumps that fired my imagination and retained my interest in it as a database technology throughout my professional career, and I’ve been able to figure out how we can make that magic ingredient accessible to modern developers in their terms and in a way that they can “get”. I think this has the potential to make modern developers willing and able to maintain and onwardly-develop the vast legacy of Mumps code, and might even spawn new interest in the Mumps database technology itself. If I’m right, I believe there really is an opportunity for a re-generated Mumps to rise, phoenix-like, from the ashes of its original incarnation, this time in the hands and under the control of the new generation of developers.
If you’re thinking that all sounds too good to be true, then watch this space: all will be revealed in the next parts of this article.