MUMPS   Home     Content    

MUMPS, what is it?

MUMPS is an interpreted computer language like BASIC. It was first developed at the Laboratory of Computer Sciences at Massachusetts General Hospital in 1967 specifically to process strings and support random-access databases. MUMPS has a built in hierarchical database that can be accessed by a programmer without having to learn a separate query language.

What does the MUMPS acronym mean

The M in MUMPS represents Massachusetts General Hospital. The remainder represent Utility MultiProgramming System. MUMPS is an interpreted language and as such carries the good and bad of interpreted languages. Of the early languages, I find MUMPS to be very powerful. Unlike other languages that concentrated on formula translation languages, algorithm languages, and business languages, MUMPS could handle strings and manipulate a database. MUMPS is as easy for a non-computer professional as BASIC. With an application like FILEMAN(ager) it could also manage a database.

The ease of learning MUMPS is both a strong point, and a weak point. Strong because a person with domain knowledge can write MUMPS code to perform operations within his domain. Weak because without some engineering training, system design and data definitions are not done before the coding begins.

Importance of engineering discipline

Robust systems go through a development cycle. Discussions with the customer are used to produce a requirements specification that the developers and the customer understand and agree to. Even before requirements specifications are in the final stage, software engineers are doing requirements analysis and forming a high-level design that includes data definitions, and test engineers are forming test plans. Once the requirements specifications are agreed to, the high level design is firmed up and detailed design and test plans can begin. It is important to have software and test involved in the requirements definition phase since a requirement that cannot be implemented or tested is useless, and can lead to legal problems.

Requirements documentation for MUMPS systems

Of the MUMPS systems I have examined to date, only one had requirements documentation. Even though the document title said requirements, they read more like a wish list, and in many cases were not testable.

Is MUMPS a bad language

MUMPS like any computer language is a tool. How a tool is used (or misused) should not reflect on the tool. I have seen some MUMPS code that is clear and clean, and I have seen some that the author should hang her head in shame. This phenomenon is not a MUMPS problem, but is caused by a lack of discipline, or a way of seeking job security.

How does poor coding practices help job security

In my early days of engineering, I met a man who wrote clean code, and documented it very well. He said that the best job security is to write clean code and document it well so that you didn't have to maintain it. In this way he said, even though is appears as though you are trying to work your way out of a job, the pride you take in your work will almost always guarantee new work.

A manager once told me that if a programmer becomes indispensable, he should be released at the earliest possible moment. I often wondered why he said that until I worked for a company where management was afraid of the programmers. It was a sad situation because the fear caused distrust. The system was a MUMPS system, but it could have happened (and probably has) with any language. MUMPS was not the cause of the problem, neither were the programmers. A problem of this magnitude can only be caused by poor management.

What happened is that the contractor (A.K.A the corporate office) wanted to win a large contract, so they took a system that provided some of the functionality of the desired system, hired an army of hospital personal, taught them MUMPS, and turned them loose on the code. I don't know how many of you have ever worked in a hospital, but I have. In a hospital, each department has its own way of doing things. Worse than that, the procedures for the same department vary between hospitals, not just between departments. Hospital personal are some of the most wonderful people you will ever meet. With all the departments with all the different procedures they can still help people improve their health through their cooperation with each other. Unfortunately, it is difficult to program the interpersonal cooperation into a computer system. And so, with hammer and chisel, this group of people managed to make a system run (somewhat).

Problem

The problem is that MUMPS code is easy to write, but hard to read, and there wasn't time to document the code. They won the contract, and the customer wanted the prototype. So now we have the customer management thinking they can save money by using a prototype. When I worked in a hospital laboratory, we had a cartoon with the caption "No job is finished until the paper work is done". I think that this holds for computer systems as well. Like an iceberg, the code is only about ten-percent of a system. If that is all you can see, the ninety-percent you don't see can sink your ship.

We don't maintain MUMPS code, we rewrite it

Sadly, a MUMPS programmer said this to me. There are good MUMPS programmers, I know some. Unfortunately, this header is what happens in too many systems. All too often, misunderstood code is rewritten to fix one problem, only to introduce more problems.

Open source

Probably the greatest strength of MUMPS systems is that since it is interpreted, the source code is delivered to the customer. However, in some modern systems, the code is run through a preprocessor, and the byte-codes output from the preprocessor are delivered without the source or the comments.