View source for 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."