You may not realize it, but the majority of us developers have been living a sheltered professional life. Sure, we’ve got that living disaster of a C++ application and that ridiculous interface between PHP and COBOL written by the boss, but I can assure you, that all pales in comparison to what many, less fortunate programmers have to work with each day. These programmers remain mostly forgotten, toiling away at a dead-end career maintaining ancient information systems whose ridiculously shoddy architecture is surpassed only by the tools used to create it. Bryan H lived in such a world for over two years. Specifically, he worked at a “MUMPS shop.”

With no experience and a three-week old college diploma, Bryan was pretty happy to land his first programming job. He had never heard of the programming language that the company used, but he was assured that he’d receive plenty of training and should have trouble picking it up. And they weren’t joking about “plenty of training.” Bryan’s first three months were spent entirely in a classroom filled with other recent grads, all learning about what the next forty years of their lives had in store: MUMPS, MUMPS, more MUMPS, and, if they were extra lucky, a dash of Visual Basic.

 

MUMPS Explained

MUMPS (originally, Massachusetts General Hospital Utility Multi-Programming System) is conceptually different from just about every other programming language out there. The primary design goal MUMPS was to create code that, once written, can never be maintained by anyone ever again. The syntax is somewhat reminiscent of FORTRAN and SNOBOL (no, not the toilet cleaner), only much, much worse. Ironically, being inflicted with mumps (the disease) is much more pleasant that actually working with MUMPS (the language). A more apt name for the language certainly would have been EXPLOSIVE-DIARRHEA; I’m sure they could have even worked SNOBOL (the language, or, heck, even the toilet cleaner) in there as well.

To give you an idea of what MUMPS is all about, following is an abbreviated list of features pulled straight from the MUMPS FAQ:

CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.

COMMANDS: may be abbreviated to one letter, case-insensitive. Includes commands such as IF, ELSE, GOTO, WRITE, and XECUTE [which is my personal favorite, it allows arbitrary execution of code contained in a variable]

OPERATORS: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.

DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.

DECLARATIONS: NONE. Everything dynamically created on first reference.

LINES: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."

LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.

GLOBAL ARRAYS: arrays that start with a caret symbol. Stored on disk, available to all processes, persist when process terminates. This is M's main "database" mechanism.

Keep in mind that MUMPS is not one of those esoteric joke languages. It should be, but it isn’t. MUMPS is very real, and has been used for the past thirty years to create and maintain colossal medical information systems.

 

MUMPS Abused

At the company Bryan worked for, they didn’t just use MUMPS, they used it cleverly. Partially as a result of MUMPS’ limitation and partially because they had all gone insane.

All MUMPS code was stored in a Global Array named ^ROUTINES. The only code that existed outside of this array was stored in “Application Startup” codefiles, each containing a single line of code: X(^ROUTINES("XSTARTGB")). The only difference between each file was the last two characters, or, the application identifier.

Within each application lived hundreds of modules, and within each module lived thousands of routines. All of these routines shared the same environment. To ensure that global arrays and code didn’t get mixed up, a strict naming convention was followed. Each routine name was no more than eight characters, and consisted of a two-character application identifier, a two-character module identifier, and a two-character routine identifier. The remaining two characters were for “routine chaining.” You see, because MUMPS has a rather small routine limit, developers had to spread code across several routines (GBLVCM1, GBLVCM2, etc) and “chain” them together with a GOTO at the end.

To edit the code stored in the “database” (if you’re charitable enough to call it that), developers needed to use the internally-created text editor. It actually made vi look user-friendly. The editor made extensive use of DEC VT 220 keys as shortcuts; these keys, naturally, did not exist on any modern keyboard. Things that we take for granted (the Enter key, for example) required a bizarre set of escape commands to be entered.

 

The Lucky Ones

I mentioned earlier that “lucky” developers were given the opportunity to work on the company’s Visual Basic components. Being the neophyte that he was, Bryan was years away from even being considered for such a role. But they made sure that all new developers saw the carrot and understood that, if they worked hard enough, they might get to savor it one day.

Like most other things at the company, the communication protocol between MUMPS and Visual Basic was homegrown. The client VB application read an unencrypted UNIX login and password from a file, initialized a telnet session, opened the MUMPS environment on the server, and then sent MUMPS code to be executed. Because their MUMPS system was so ridiculously slow, it would often take minutes for a simple operation to complete. Reports would take hours.

 

Bryan’s Job

The company was not too worried about poor performance because they only went after huge companies. This meant that they could blame the lag on the huge amount of data their clients used. Despite that, they still had a Performance Enhancement Team. That was the team Bryan was assigned to work on.

The Performance Enhancement Team did not work proactively. They worked reactively. When a client had “emergency performance problems,” they’d create an emergency fix and save the “real problem” for “another day.” Obviously, that day never came.

 

A Way Out

On the eve of his second year anniversary, Bryan finally realized something. He had been a MUMPS programmer for two solid years. Outside of his current employer, the skills he now possessed were not only worthless, they made him a pariah. Honestly, would you want to hire someone who had only used such a language and environment?

With his only alternative being a future filled with MUMPS, Bryan knew what he had to do. Without any job prospects, he put in his two weeks notice and prayed that he’d be able to find a new job without any noted work experience and a two-year old college degree.

As of this writing, Bryan is still unemployed, trying to land that “first job” again. But he has landed a few job interviews and is hopeful. One thing he’s sure of is that the next forty years of his life will not be filled with MUMPS, MUMPS, and more MUMPS. At least, we can only hope...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!