Tom Munnecke posted a video of conversation we had about refactoring, design, and VistA. I agreed with most of what he had to say, but at the time of the conversation I was uncomfortable about what he said about decomposition and how he used the story of the blind men and the elephant. If you don't know that story, see the poem that introduced it to the west, or the Wikipedia article. I use the story when I teach OO programming. I give three different views of OO programming, and say that they are all true, but each view is limited. OO is a culture, and no description of a culture can be complete.
Science (and western thought in general) is based on reductionism, on making models, on abstracting. It is a very powerful tool. But patterns are very much about balancing forces, about appreciating the disadvantages of a technique as well as the advantages. The story of the blind men and the elephant is useful because it warns us of the dangers of reductionism. The story seems to have been told originally to warn against religious claims to exclusive truth. But Tom used it (and I do too) against a more broader narrow-mindedness.
Most people do not want to be narrow-minded. We want to be "right-minded", i.e. to see things correctly. When you tell someone they are narrow minded, they tend to get mad at you. But if you say "you are forgetting this part of the problem" then they are more likely to actually think about it. They might end up agreeing or disagreeing, but they will at least talk about it with you. We all know it is easy to miss things, that we only see part of the situation.
One of Tom's metaphores is a cat; once you disect a cat then you can't put it together again. It is not a good metaphore for understanding, because we could draw blood samples from a cat or take X-rays of it without killing it. Blood samples are only a tiny part of a cat, and only show us a fraction of what it is, but sometimes a veterinarian can learn something important that way. However, it is a great metaphore about making changes to a system.
I think that Tom uses the cat metaphore because he is concerned that the VA has made large changes to VistA without understanding it, and these changes involve cutting out parts of it without realizing that the parts that are cut out are deeply connected to the others. From talking with him, I can see three things that he thinks people have ignored.
1) Tom sees VistA as much more than just a piece of software. VistA is a community, a process for working with the software, a knowledge base. One of his original purposes of building VistA was to create a community, and he not only succeeded but is proud of how he succeeded. So, it pains him to see people try to reuse the software but at the same time ignore the community, and perhaps even supress it.
2) VistA was developed in a bottom-up fashion. Each hospital had a few programmers, and each programmer worked closely with doctors. There was no overall architect or plan, other than improving the health of veterans. This process undoubtedly had some weaknesses, but it had tremendous benefits, as well. It resulted in a system that fits the needs of doctors. It is a major reason why VistA has been so successful, and the VA has worked hard for 15 years to try to have a more top-down development style, and has been impressively unsuccessful.
3) VistA is driven by metadata. Metadata means different things to different people, and VistA has a variety of kinds of metadata. Sometimes it means the data that indicates the provenance of the real data, and VistA has that. But the kind that interests me the most and that I think interests Tom the most is configuration data that controls the behavior of the system. Most hospitals that use VistA have a cadre of medical experts (usually trained as doctors or nurses) who configure VistA. Most of the work of configuring VistA to a hospital does not require programming in Mumps, but just changing the metadata. This means that the details of VistA are under the control of medical experts (who have to become VistA experts before they can exert this control) and not programmers. Tom thinks that VistA should have a lot more metadata, and that there are a variety of things in VistA that now require programming that ought to be done by the experts who configure metadata.
These three aspects of VistA (and I expect there are more; these are just the three I can recognize) contribute to making VistA such a good fit for healthcare. Healthcare varies enormously, and it is hard for one piece of software to fit everywhere. The second and third aspects are part of what makes VistA so configurable; the first aspect helps people to learn how to configure it.
This description of VistA is just the parts of the elephant that I have felt. It is a complex system and perhaps is not knowable by any single person, no more than a city can be completely known or the internet can be known. Nevertheless, I know Champaign pretty well and I know Chicago better than I know New York City, though I know New York City better now than I did a year ago. I look forward to getting to know VistA better.