3) How hard is it for non-Mumps IT personnel to learn Mumps/VistA and are there enough experienced VistA programmers (or former VistA programmers) to consult or be hired to non-VA projects?

     Learning MUMPS is as simple as learning BASIC.  Learning about all
     the utilities and capabilities of the common services in VistA is
     a years long process.  And learning the functionality and setup 
     for the clinical and administrative functions in VistA would
     probably take several life-times. Are there enough experienced 
     programmers and Application consultants?  So far I believe you'll
     currently pay more for a Java programmer.

     I am a physician and have taught myself M.  It is a very simple
     language.  I consider it to be a scripting language.  But it gets
     the job done, and has run hospitals safely for decades.

     There are many people on the list that would like work as 
     programmers, so I don't think there will be any limitation there.
     And when CMS releases VistAOffice, there should be even more 
     interest and consultants available.

Rick Marshall replies:

It is easy to learn Standard MUMPS, but impossible to master VistA. Like the art of medicine itself, VistA is complex beyond human comprehension--no, I am not kidding or exaggerating--and no one person will ever know it all anymore. I have been programming with VistA for twenty-one years; there are a couple areas of the code I know better than anyone, several I know as well as the other experts, and a dozen or so I know reasonably well--out of 80-120 software packages, depending on where you draw the lines. Most of VistA I know by its patterns and common structures, and maybe a few basic architectural features per package, but for most of VistA I am the wrong person to go to. There are whole packages I know only by name, whose purpose I can only guess at. So it is with all the VistA gurus. None of us pretends to know it all or even most of it. We work together as a community, sharing out the vast scope of work that is VistA among ourselves.

To address your central concern, our tradition is to grow our own new Standard MUMPS and VistA programmers from among its users, because we have discovered it is far easier to teach a nurse to program than to teach a programmer to practice medicine; the nurse has already mastered the difficult part. It takes mere minutes to start writing Standard MUMPS code, as with any programming system worth discussing, but a day or two to introduce the basics, a week or two to introduce them fully, and a month or two to become fully comfortable with the programming system. It takes experienced programmers longer to learn Standard MUMPS, because it is not like most other programming systems, and they spend years whining about it instead of buckling down and coming to grips with it on its own terms. Learning Standard MUMPS is like taking small steps over very deep crevices; it is easy but unnerving for some.

Learning to program with VistA takes longer, and should happen in two phases. First the programmer needs to learn our programming standards and conventions and common calls. Then the programmer needs to pick a package and focus on it for a long time, moving from simple assignments to more complex ones. It is best if the student began as a user of that package, then graduated to being an Application Coordinator (a kind of super-user) for it, before learning to program with it. Becoming an expert user of any reasonably sophisticated VistA package takes years. Once an Application Coordinator starts training to become an information manager, starts working on supporting and extending a package at a site, every year they keep at it improves their skills with the package measurably. Those who have worked with a package for ten years or more are easy to tell apart from those who have only been doing it a few years.

There is a lot more I could tell you about the expertise lifecycle, how it is structured, where to find VistA experts and how to grow your own, but I am trying to keep this postscript "short."