VISTA Expertise Weblog

Electronic Health Record VHA-Wide Medical Scheduling

2012-01-31T16:52:00.000-08:00

Download our response to the Department of Veteran Affairs Request for Information VA118-12-I-0102 on the Services page of our website.

Meaningful Use certification at Oroville Hospital

2011-12-15T14:06:00.000-08:00

A local news piece on our friends at Oroville Hospital, with Dr. Narinder Singh.

Carol Monahan: Introducing Myself

2011-12-13T15:50:00.001-08:00

As the new director of support at the VISTA Expertise Network, I have had the opportunity to spend the last few months learning about the VISTA community. I was delighted to meet so many dedicated people at the recent VISTA Expo & Symposium, and I want to thank everyone who participated in our session on open-source licensing.

I have a decidedly eclectic background, including a grounding in computer science, with extensive managerial experience in sales, logistics and ERP planning, while working at Wizards of the Coast. On a lighter note, my first job was as an assistant to a couple of large- and small-animal veterinarians in Ireland, and I have also worked as a Tiffany salesperson, and a "spokesmodel", meaning that I got to hand out ham samples at a trade-show. Generally speaking, I enjoy a challenge.

I'm looking forward to promoting community licensing solutions and codebase reunification, as well as getting to know more of the excellent VISTA Hardhats.

More About Us

2011-12-13T15:28:00.000-08:00

Here is some additional information about VISTA, the VISTA Expertise Network, and our goals and approach. If you're visiting us for the first time, please also read the "About Us" tab.

Background:

The VISTA Expertise Network was set up to promote the use of open-source VISTA software. VISTA is more than just an electronic health record (EHR). It is an entire suite of fully-integrated clinical support programs, built on a powerful database engine designed from the ground up to support the practice of medicine. VISTA was created over the course of three and a half decades within the Department of Veterans Affairs (VA), and a close cousin is in use within the Indian Health Service (IHS). An adaptation of an earlier version is also being used by the Department of Defense (DOD). It has been successfully adapted for use outside of governmental systems, using an open-source approach to build on the public-domain codebase supplied by VA, under the Freedom of Information Act.

Until fairly recently, VISTA development was driven by the direct involvement of VA clinicians, using an agile, adaptive process. Unfortunately, a drive toward homogenization and centralization has led to a severe slowdown in innovation within VA. Facilities using VISTA outside VA have been hampered by having no communication back into the VA system, meaning that VA updates and upgrades—although welcome—are developed with no consideration for non-VA users. VA has also suffered from diminished direct user feedback in their development cycle.

During the last decade, the bureaucracy’s response to this “death of innovation” has been to pursue a wholesale replacement of VISTA, which has been branded as a “legacy” system, implying that it is outdated—even though it still supports a higher quality of care than any newer system has been able to demonstrate. This has lead to a series of very expensive, failed initiatives. Fortunately, this year, VA is experimenting with a new approach—setting up a custodial agent (OSEHRA) and working to create an open-source development ecosystem where outside contributions can make their way back into VA, IHS, and DOD systems, and variations within those systems can be shared to create an even richer pool of options for all VISTA systems. On the downside, some VA and DOD managers involved with the project still seem to hope that this will result in a wholesale replacement of their systems with “plug and play”, “modular” software.

Our Goal:

The VISTA Expertise Network believes that VISTA can continue to evolve and adapt, building on its track record of proven success. To that end, we have dedicated ourselves to both promoting adoption of the software and training a new generation of programmers and users.

Our Approach:

There is a pressing need for EHR software among underfunded rural hospitals. New legislation dictates that hospitals that cannot show Meaningful Use of their EHR will begin seeing reductions in Medicare and Medicaid (CMS) reimbursements beginning in 2015. These hospitals could receive ARRA funding toward purchase of EHR software during the next few years, but many do not have sufficient capital on hand to get the process going, leaving them unable to qualify for assistance, and facing penalties all too soon.

VISTA, as open-source software, can save these hospitals the large licensing fees associated with most commercial hospital software. It does, though, still require configuration, customization, and training of both IT staff and end users. VISTA Expertise Network recruits and manages the experts necessary for both installation and training.

One criticism that is leveled at VISTA is that it is “old fashioned,” since many functions within the system still rely on text-only user interfaces. The VISTA Expertise Network has collaborated with Dr. Rob Tweed of M/Gateway in launching the development of a new generation of user interface for VISTA, using Enterprise Web Developer (EWD) software. The new interfaces are device-independent, allowing them to run on anything from a PC to an iPad to an Android phone. The underlying system is unaffected, but the user experience is brought right up to date. The VISTA Expertise Network is promoting training of programmers and adoption of the new interfaces.

The VISTA Expertise Network is committed to creating the best training materials and courses to prepare programmers and users to gain the full benefits of VISTA. With our emphasis on promoting projects at hospitals and clinics in underdeveloped rural areas, we have the opportunity to create skilled jobs (and the skilled workers to fill them) right where they are needed the most.

2012 VISTA Expo & Symposium, 11-14 September, Where?

2011-12-13T15:18:00.000-08:00

Now that the 2011 VISTA Expo and Symposium has concluded, we are hard at work on planning the next conference. We have tentatively selected September 11-14, 2012 for the next VISTA Expo and Symposium. Our next task is to choose a location.

The Marriott in Redmond was wonderful, and we are in conversations with them about using them again. However, we are strongly considering making the VISTA Expo and Symposium a moving conference, holding it in a different place every year. To that end, we have identified two other possible cities for 2012.

One possibility is Reno/Sparks, Nevada. It has the advantage of being close to Oroville Hospital, one of VISTA’s early Meaningful Use success stories. It also provides an opportunity for a couple of days’ vacation, if people would like to come a little early or stay a little late.

Another possibility is Albuquerque, New Mexico. Its principal advantage is that it would make things easier for our friends in Indian Health Services, so that more of them might be able to attend. And Albuquerque is also a lovely place for a few extra days.

We are getting opinions and feedback from a variety of sources, and we are interested to know what the hardhats think. Redmond, Reno, or Albuquerque? Which would you prefer for the 2012 expo?

24th VISTA Community Meeting

2011-12-12T16:30:00.000-08:00

WorldVistA is holding its twenty-fourth VISTA Community Meeting Friday through Sunday, 13-15 January 2012 at the University of California, Davis, in Sacramento. Owen Hermsen, Chris Richardson, Larry Landis, David Wicksell, George Lilly, and I (and possibly another Network staff member to be named later) will all be attending. We look forward to seeing you there. We all have a lot to talk about and plans to make together.

Since the conference is just a month out, this is a good time to make your travel plans while flights are still cheap. Head on over to the WorldVistA website for details and registration.

VISTA Planning and Management Part 3: Do the Right Thing

2011-09-14T07:05:00.000-07:00

When you aim for the wrong target, success = failure.

Most of the challenge in VISTA management and planning lies not in hitting the target but in choosing the right target.

Usually, it doesn’t matter how hard it might be to achieve our VISTA project goals, because their success or failure is irrelevant. Most failed VISTA projects were pointed at the wrong targets. Hitting the target does you no good when it’s your own foot you’re aiming at.

We try too hard to accomplish our goals, and we don’t try hard enough to choose the right goals. When we aim our organizations in the wrong direction, even vast budgets and resources cannot help us; on the contrary, the greater our progress, the worse off we are.

Successfully leading the organization in the wrong direction has been the paramount problem with VISTA development efforts since about 1998. The further VISTA managers have led our community toward badly chosen technological targets, the less productive VISTA development has become. It cost billions of dollars more to inch VISTA marginally ahead during the past fifteen years than it did to achieve the miles of progress we made before that.

We are failing because we pursue the wrong goals, but we are not learning from our failures.

A recent study of human rationality discovered that when people who subscribe to mistaken ideas are confronted with irrefutable evidence that they are mistaken, instead of acknowledging their mistakes and changing their minds they tend to cling more fiercely to their now discredited ideas. This same thing happens to those of us who lead our organizations in the wrong directions. Rather than stop to reconsider our goals, we recommit ourselves and our resources further, at most revising our tactics so we can head in the wrong direction more effectively.

There is a lack of introspection about our choices of goals. We treat requests for reconsideration as indecisive, impractical, and irrelevant, as though the main danger we face were a lack of effectiveness rather than an excess of effectiveness in the wrong direction. We believe it is our job to be go-getters, proving our worth as managers by the amount of movement we can create rather than by the rightness of that movement.

We behave as though agreement about our goals corresponded in any way to whether those were the right goals. In the real world outside the Beltway of Washington D.C., neither majority agreement nor even consensus matters. The real world is not impressed by our opinions, our votes, our public relations, or our change-management strategies. Even if everyone agrees the Sun revolves around the Earth, the converse remains true.

The laws of information science are just as relentless and implacable as those of rocket science. We defy them at our peril. Nothing can save from failure a project aimed in the wrong direction unless we reconsider and correct its goals.

The search for the right targets is the first duty of a VISTA manager or planner, and learning from failure the second.

VISTA Planning and Management Part 2: The Paradox of Success

2011-06-07T11:16:00.000-07:00

The Paradox of Success: Not Every Problem is a Nail

Past success with other projects can lead directly to failure with VISTA projects. The greater the past management success elsewhere, the greater the chance of failing to manage VISTA successfully. It is not an absolute correlation but a strong one and a major risk.

The problem is not unique to managing VISTA. It is an under-recognized problem in life generally, most famously described as Maslow's Hammer:

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." -- Abraham Maslow, The Psychology of Science: A Renaissance, 1966

and earlier described and explained as Kaplan's Law of the Instrument:

"The price of training is always a certain 'trained incapacity': the more we know how to do something, the harder it is to learn to do it differently . . ." -- Abraham Kaplan, The Conduct of Inquiry: Methodology for Behavioral Science, 1964

As with any other faculty, human beings only use part of the possible range of management strategies. The ideal manager would be expert at the complete suite of possible approaches - and no doubt in moments of pride we tell ourselves we have mastered them all, that we fluently use all the tools at our disposal, the right tool for every job - but in our more sober moments we know it is not true.

We are creatures of habit. We tend to lean on our strengths and avoid our weaknesses. Whichever strategies we use on the projects that go well, we tend to use again in future projects, and because we keep using them we tend to get better at them and lean on them further. Conversely, the strategies we did not use in the past tend to atrophy, so we avoid them in the future.

The result is that we try to hammer every problem into submission. We overuse our previously successful strategies even when they do not apply. The more successful we have been, the more likely we are to try to force new problems to fit our past strategies. The most successful managers tend to be the greatest offenders.

Where managing VISTA is concerned, this has been a big problem in the past and can only continue to be so in the future - unless the problem itself can be put on the radar, can be made a part of the strategy of managing VISTA. If VISTA managers can recognize the impact of the problem and force themselves to approach each project with an open mind, and if we can force ourselves to better develop the strategies that have not worked in the past, to create a more well-rounded suite of strategies, then we will be better able to do justice to the problems VISTA presents, better able to plan and manage VISTA projects successfully.

For example, we will be better able to accept VISTA's true complexity and shift strategies to something capable of dealing with something so vast and intricate.

VISTA Planning & Management Part 1: Complexity

2011-05-26T20:41:00.000-07:00

Complexity: Michelangelo's Sistine Chapel ceiling fresco.

When VISTA projects fail, it is almost always for one reason - a gross underestimation of the complexity involved. VISTA is one of humanity's most complex creations. It pushes far beyond our capacity to fully comprehend it, and therefore to successfully make plans about it as a whole.

VISTA projects that might succeed are easily distinguishable from those that will fail. Right at the beginning, during the initial planning is when most VISTA disasters are wound up like a clockwork mechanism, after which they run down to their inescapable conclusion regardless of the intelligence, experience, power, funding, or passion of the project's participants. Prudent and experienced VISTA strategists can look at the initial sketches and tell promising from doomed within minutes at a better than 90% rate of accuracy. This skill can be learned by those new to VISTA planning and management, if they can come to grips with VISTA's complexity.

Part of why it is so easy for us to distinguish them is that VISTA projects doomed to fail are rarely close; they rarely almost succeed, barely fail. They almost always fail spectacularly because the plans underestimate the project's complexity not by a little, not double, not ten times, but usually over a hundred times, and sometimes by a thousand times or more.

If you feel disbelief at this claim, we understand, but we are right about this. It is measurably true. Most of the known VISTA-project failures of the last fifteen years were off by two to three scales of magnitude in their estimation of the problems they planned to solve, and their eventual failures were usually predicted at the outset by experienced VISTA engineers. If you can accept the truth of this situation, you must be asking yourself the question all of us have asked - and to become a great VISTA planner and manager, you need to understand the answer - Why is VISTA so complex?

There are two answers.

First, for forty years the software industry has suffered from The Software Crisis. At the same time hardware has grown more powerful, faster, smaller, and less expensive, software has been growing slower, larger, and more expensive. The cause of this crisis is an inevitable paradox: with software, success leads to failure. The more programs you write for your system, the more you have to take into account to write the next program. The more you write, the harder it gets. In the world of software, that is the price of success. Given time, we can create systems so complex that we cannot manage them.

Second, healthcare is staggeringly complex, and VISTA's purpose is to help support healthcare, so it too must be complex. There is no way around it. To make VISTA less complex, you must make it less useful, that is, you must sacrifice patient care or hospital-support services.

We refuse to do that, so we must accept and plan for VISTA's complexity. That means changing the planning and management strategies with which we succeeded in our careers until now. We must switch to less well-known strategies that can deal with VISTA's complexity successfully. If we do, our VISTA plans too must change so they can succeed.

Reunification

2011-01-21T18:59:00.000-08:00

Mumpster has consumed my VISTA-blogging energies lately, but I'll be returning over the next few weeks to discuss a long-overdue topic: reunification of the VISTA dialects. I understand the factors that have prevented it until now and I have solutions for all of them. I believe that by March 1st, we will have a commitment from most of the major VISTA adopters and developers to reunify around a shared, common code base and a common license.

Watch this space for regular updates on progress toward that goal.

Mumpster

2010-11-12T08:21:00.000-08:00

We've launched a new MUMPS Users' Group on the web. Our first project is Mumpster, an online discussion site dedicated to the MUMPS programming system.

Values Conflict

2010-06-23T21:13:00.000-07:00

[1777 painting by Jean-Baptiste Greuze of Benjamin Franklin, who exemplified both the need to choose among values and the ability to do so (Wikipedia)]

The first thing to understand about the tension between class-three and class-one software, that is, the tension between local and national development - that is, between innovation and standardization - is that there is that tension and it's neither subtle nor something you can safely ignore.

The important thing about values like innovation and standardization is not that we want them, but (a) which we are willing to sacrifice to get the other—how we prioritize them—and (b) how exactly our systems for achieving one are related to our systems for achieving the other—how we relate them.

The choices we make between values define us as individuals, organizations, cultures, because we can't have everything we want. When Benjamin Franklin wrote They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety, he was making a choice that helped define a nation. Our choices have consequences.

So do our failures to choose. They who give up essential liberty for safety almost never realize they are making a choice. They think they can strengthen one value without weakening another, if they even realize the two are related at all.

In modern, scientific culture, we like facts and theories and plans but we're pretty stupid about values, because generally we ignore their conflicts; we think we can have our cake and eat it too. Our mission statements read like Christmas wish lists, as though all our problems would be solved if we could just have all the great things on our list. We don't think we have to choose, but we do.

All good things come to those who wait, we are told, but no one tells us those good things arrive in a knock-down, drag-out fight. Values conflict. Every single value conflicts with every other value.

Heraclitus wrote "War is the father of all things." This is the war he meant: the invisible war among principles that creates reality, and the all-too-often unconscious war among values that creates us.

In this all-consuming war, no man is an island; no one stands apart, a neutral power. We all take sides, willy-nilly. Since we naively believe our values don't conflict, we take sides nilly, unconsciously, by default.

As a result, within each organization, through random, ignorant selection, for each pair of values one will tend to be exalted because its merits are better recognized, but then out of balance it will crush the other value and the organization will suffer for its loss, baffled by how the pursuit of good could have led to such an evil.

The only way to have both values in a competing pair is consciously, through a deep understanding of the nature of the conflict between them, so you can realize how to bend back the conflict into a self-reinforcing flux, a homeostasis. That rarely happens by accident in the conflicts among human values, and it never, never happens when a bold leader pushes some values at the expense of others.

With that understood, let's examine innovation and standardization and the conflict between them, so we can begin to understand how the VISTA community once achieved homeostasis between them and will again soon.

VISTA & Homeostasis: An Introduction

2010-03-08T09:55:00.000-08:00

[1638 engraving by Peter Paul Rubens of Hippocrates of Kos, whose precept "First, do no harm" is one of the foundational principles of medicine (Wikipedia)]

Dear Reader,

Would you want to be treated by a doctor who doesn't understand the importance of the circulation of your blood? What if he knows it's important but not that the heart has anything to do with it? Would it be okay with you if he knows the heart's involved but not the brain?

In general, how much would you trust your health to someone who doesn't understand what keeps you healthy?

People were successfully treated for millennia by care providers who didn't understand these or other systems but who did know to be cautious with the things they didn't understand. They knew that if it ain't broke, don't fix it. They abided by the fundamental medical principle, First, do no harm.

What happens when people subvert this principle, when they decide a better fundamental principle would be First, get control?

Replacing the Hippocratic principle with a totalitarian one leads to scenarios like this: your doctor removes your brain when he becomes your primary care provider because it's too complicated, difficult to manage, an irritating distraction, always making your body do things without first consulting him, probably not important anyway because he can tell your heart when it needs to pump.

We make physicians swear an oath to uphold Hippocratic principles before we let them treat patients, in part to help prevent things like that from happening. Too bad we don't make medical-software programmers and managers swear the same oaths.

Over the last fifteen years, VA central management has been conducting dangerous and unnecessary surgery on VISTA's lifecycle, removing all of its living systems one by one and replacing them with simple mechanical controls that put central office in charge of everything. They call this getting VISTA under control.

As a result, VA's VISTA program is in a state of accelerating collapse that's passed the tipping point, yet VA keeps trying even harder to control and centralize VISTA. Doing the same thing but expecting different results . . . there's a word for that.

To help you understand why the way VA used to manage VISTA was healthy and why the last decade and a half have made it sick, I need to teach you about VISTA's vital signs and systems, the processes that make VISTA development healthy. All of these systems are based on homeostasis, so they're self-correcting when we let them do what comes naturally to them. To break those systems you'd have to dismantle their built-in self-correction and try to take control of them yourself. Sound familiar?

Let's start with one of two VISTA homeostatic systems that balances innovation against standardization—the tension between class-three and class-one software, that is, the tension between local and national development.

Yours truly,
Rick

The Hidden Harmony & Homeostasis

2010-03-05T09:26:00.000-08:00

[Diagram of blood-insulin and blood-sugar levels over the course of a day, from the Wikipedia article on Blood Sugar]

Dear Reader,

The hidden harmony is present but often easy to overlook in the realms of math, physics, and chemistry, but biology demands an intuitive understanding of it because living systems exhibit all kinds of behavior that at first seems to contradict the rules and principles of these foundational sciences.

For example, consider the second law of thermodynamics (In a system, a process that occurs will tend to increase the total entropy of the universe, or, things tend to run from order to chaos, tend to run down, always increasing the unverse's entropy). It nicely explains aging, disease, and death but seems contradicted by conception, embryogenesis, evolution, and development (not to mention the Big Bang itself). Someone steeped for decades in the "hard sciences," when confronted inescapably by large-scale biology's many seeming contradictions of the hard-science principles, can either (1) turn away from biology and back to their more comfortable fields, (2) resort to miracles for explanation, or (3) search for additional cosmic principles that contradict principles like entropy, that wind things up instead of winding them down.

The second form of fluxus quo, the hidden harmony, intuitively explains what the second law of thermodynamics, entropy, does not—the capacity of living things to run from chaos to order, to wind up, to decrease an organism's entropy by unfolding layers of increasing order. The self-assembly of living systems is a miracle from the perspective of entropy but inevitable from the perspective of the hidden harmony.

In its simplest, easiest-to-explain form, the hidden harmony manifests in the ways living organisms work to maintain steady temperatures, or blood pressures, or access to glucose, or so on. This quality of living things, called homeostasis, produces what at first seem to be comparatively steady states through the harnessing and control of opposing forces.

One example of this is the way insulin and glucagon set in motion opposing tendencies with regard to the regulation of blood-sugar levels. When they rise too high, a healthy pancreas releases insulin to instruct cells to absorb more glucose from the blood, thus lowering the blood glucose levels. When they fall too low, the pancreas releases glucagon to instruct the liver to convert more glycogen into glucose and release it into the blood, thus raising blood glucose levels. Over the course of a day, blood-glucose levels are almost never at a steady state, never a status quo; rather they are always rising and falling in response to digestion and the cells' consumption of blood glucose, and when those cycles spike erratically from the consumption of sugar or from excessive energy demands the body intervenes with insulin or glucagon to channel them back into the narrow band of blood-sugar levels that supports human health.

Living systems are densely woven with such homeostatic systems for preserving an organism's health, as is the cosmos itself, since we evolved to be healthy within the normal conditions of our environmental niches.

[Photo of James Heilman juggling from Wikipedia article on Juggling]

In all these cases, the appearance of stasis is an illusion; both forms of dynamism are always in operation. First, there will be a cosmic river—an overt flow of materials and energies upon which life depends. Second, there will be a hidden harmony—two or more primary systems set in opposition to channel, set in motion, and modulate that cosmic river, and many secondary systems that stabilize and reinforce the primaries.

With all this flux going on, it shouldn't be called homeostasis. It should be called homeoflux.

Like juggling, any apparent steady state is actually a state of continual change (the moving balls) that is itself driven by a more fundamental underlying pattern of change (gravity, mass, and the juggler). If, for fear of dropping the balls or making a mistake the juggler tried to just hold them still, the act of juggling would be at an end, the episode of juggling would die, because in a truly living system it is the fluxus quo that produces what we think of as the life within the system.

So it is with the human body. The flow of blood, lymph, cerebrospinal fluid, air, food, water, hormones, nerve impulses, chemical reactions triggered by photons striking the skin, the flowing transformation of biochemicals along metabolic pathways, and many many other things beside, the flow of all these things must continue for our life to continue. Stop even one of these flows, and sooner or later we sicken and die. The body is not flesh at all but is instead a flow, a nexus, a crossroad of many rivers, and we die when the rivers stop flowing through us, when they go their own ways and leave us in an apparent status quo (although the truth is that we go on flowing in different ways after we die, as we dissolve into the tributaries of other rivers).

So it is with managing VISTA. The effort to control VISTA, to hold it tightly, to decide what will and will not get worked on, these efforts kill a VISTA adoption. All of the elements of the VISTA model have to actually flow channeled but unimpeded to create a homeostatic VISTA system capable of supporting a hospital. A VISTA lifecycle is a living system, a form of nonorganismic life, in which the flow must go on; thirty years of experiments with the alternatives have proven the truth of this to anyone who has bothered to learn from its history.

At this point, if you don't feel comfortable with the fundamentals of fluxus quo, I'm gong to say the burden is on you now to ask about it. Fluxus quo is one of the essential principles that makes VISTA work, but as for what must flow and how—the fundamentals of its health, to succeeding with VISTA adoption—well, the devil's in the details, and it's time to talk about them.

Let's move now from the principle to its manifestations. Let's explore some of the homeostatic systems that must function correctly for the production, development, and maintenance of VISTA.

Yours truly,
Rick

Fluxus Quo: The Cosmic River & the Hidden Harmony

2010-03-04T21:47:00.000-08:00

Dear Reader,

Recap of this entire blog using our new terminology: The VISTA community achieved a harmonic fluxus quo from 1977 to 1995 by harnessing homeostasis, modeled on the way biology harnesses flux to achieve stability. We will preserve and extend today's VISTA renaissance the same way, because it is the only sustainable path available to human beings, the only way to transform very complex interactions and dependencies into a self-reinforcing system.

Now, to explain homeostasis: Wikipedia and other traditional references are going to be of limited help here, since they explain it at only the most shallow, Platonic level, like a mechanism, without any appreciation for its cosmic significance. We need to define it in terms of fluxus quo.

For the discussion that follows, we need more concise terminology to describe the two main expressions of fluxus quo, because homeostasis uses the second to channel the first, which will be hard to explain without more descriptive terms.

I considered borrowing the contrast between kinetic energy and potential energy from physics and applying it to flux, but that dichotomy is too Platonic, built upon the assumption of stasis as the normal condition in which energies can be wound up (potential) and discharged (kinetic) according to the principle of entropy. Instead, let's use rich metaphorical terms borrowed directly from Heraclitus, the original philosopher of flux.

For the first kind of flux, the nonstop change in all things that goes on around us all the time, whether we see it or not, let's call it the cosmic river, the one you can't step in twice because it is always changing and so are you and everything else.

For the second kind of flux, the invisible flow of principles whose conflict produces the cosmic river, both the things in it and their flow and transformation, let's use the term hidden harmony, to capture the idea of the harmony in the bending back of forces against one another to produce apparent stability.

Now for homeostasis itself.

Yours truly,
Rick

What Does Fluxus Quo Do?

2010-02-10T23:32:00.000-08:00

Perito Moreno Glacier Patagonia Argentina. Photo taken by Luca Galuzzi (http://www.galuzzi.it).

Dear Reader,

Fluxus quo acts upon our world through two kinds of dynamism: flow that results in motion, and flow that results in stillness.

First, everything is actually moving and changing even when it appears not to be. The appearance of the world is stability interrupted by intervals of change—punctuated equilibrium, as Steven Jay Gould called it—but the deeper truth of the world is flow. Look up from your computer screen and look about your room. Not a single thing you can lay your eyes upon is genuinely static. The glass is a liquid, ever so slowly oozing its way toward the bottom of the window, which is why old window panes are rippled. The paint, the wood, the fabric, all of these organic materials are slowly converting their volatile organic components via chemical reactions into gas, which is evaporating into the air, some of which you're inhaling. Every scrap of metal is like the glass, congealed into solid metal only because of how cold it is, but someday, sooner or later—a thousand years, a million, a billion—the metal will be hot again and will resume its liquid flow, and until then electrons readily flow within many metals creating electrical currents. Certainly all living things you can see are always engaged in both internal flow and many cyclic flows of interactions with the greater world around them. Seven years from now, some of their physical makeup will be the same—lead or mercury poisoning unfortunately—but most of their cells will have been replaced with new ones.

Stasis, things holding still or being what they are and only what they are, is partly an optical illusion, like a single frame of a motion picture, a moment caught in a strobe light. Seen for a brief enough instant of time, even a river appears to be a complex frozen ripple, in a photograph or the blink of an eye. Seen for a long enough period of time, the misunderstanding that a glacier is merely an enormous frozen river breaks down and the river of ice it truly is can be seen to flow, which it is always doing regardless of our limited perception of it. As Homer wrote, all human beings are ephemeroi, creatures of a season, like leaves on a tree. Our lifespans are far too short to see any but the fastest flows; the apparent stillness of so many things that our flashes of life illuminate are optical illusions, a trick of mortal perspective.

Heraclitus expressed this form of dynamism in several ways:

One can grasp no mortal substance in a stable condition.

It scatters and gathers, it forms and dissolves, approaches and departs.

Everything flows and nothing abides.

You cannot step twice in the same river.

Second, the pace of change does actually accelerate or slow in response to another layer of flow under the physical surfaces of the cosmos. Physical forces and organizational principles of the cosmos conflict with one another, subvert one another, tangle and release, and otherwise interact in complex, shifting ways so that the pace of change for any given thing is sometimes rapid, sometimes so slow as to create near stillness. When things are briefly still, it is because the forces within them are balanced enough to convert their dynamism into internal stresses instead of external motion.

Like a taut bowstring, these kinds of situations are pregnant with energies waiting to be unleashed. To a literal-minded person, a bow held undrawn and a bow held drawn are both just things, objects, static, but to one with eyes to see, the drawn bow is a wound-up explosion of change about to happen. Viewing the world in terms of the objects or things leaves you perpetually surprised by earthquakes, tsunamis, wars, terrorist attacks, and other kinds of sudden change, but truly it is during the apparent still periods preceding those disasters that the problems were created, that the invisible energies tangled up and pulled one another into tension. Part of the secret to the cosmos is that the visible things we cherish or fear are merely the side effects of the movements and conflicts of the deeper principles that underlie everything. That is, as important as it is to come to understand the flow of the things that make up the visible cosmos, it is the invisible flow of the principles and forces of the cosmos that actually produces everything we take for real.

Heraclitus wrote about this form of dynamism too, as an endless war that creates and sustains the harmony of the cosmos:

It should be understood that war is the common condition, that strife is justice, and that all things come to pass through the compulsion of strife.

Homer was wrong in saying, "Would that strife might perish from amongst gods and men." For if that were to occur, then all things would cease to exist.

It is in changing that things find repose.

Opposition brings concord. Out of opposition comes the fairest harmony.

People do not understand how that which is at variance with itself agrees with itself. There is a harmony in the bending back, as in the case of the bow and the lyre.

The hidden harmony is best.

Fluxus quo cannot be stopped to create stability, nor can it be ignored since it permeates and shapes all things, yet these are the two strategies most people try. Nevertheless, if we want to produce anything lasting in this world we cannot just go with the flow, or else the first form of dynamism created by fluxus quo will simply scatter our efforts in the river of time, but the second kind of dynamism it creates can and does paradoxically produce a dynamic kind of stability, what Heraclitus calls the harmony in the bending back.

This is the secret to harnessing fluxus quo, to achieving success with something as complex as VISTA. If we try to stabilize the things in the VISTA community that we want, our efforts will be swept away, but we can instead bend back the underlying forces that produce and organize those things so they conflict with each other to produce a harmony, a dynamic, self-reinforcing stability. In such a harmonic configuration, the flow of fluxus quo strengthens the stability instead of breaking it up.

A bow may be dynamically stabilized with two primary counter-reacting forces, from the wood and the string—with additional forces introduced when it is drawn, of course—but for something as complex as VISTA we need a more complex harmony between more forces. That would seem to reduce the odds we can keep them stabilized, but another field of study reveals that even complex harmonies can be achieved using a specialized method of bending back the forces upon one another.

The field is biology. The method is homeostasis.

Yours truly,
Rick

What is Fluxus Quo?

2010-02-08T23:41:00.000-08:00

Supposed bust of Heraclitus from the Villa dei papiri in Herculaneum (bronze, Roman), Naples National Archaeological Museum

Dear Reader,

Just as Parmenides and Plato were the preeminent Hellenic philosophers advocating a static understanding of the cosmos, so Heraclitus was the preeminent Hellenic philosopher advocating a dynamic understanding of the cosmos. Although dismissed by the ignorant as a philosopher asserting that all things were made up of the element fire, Heraclitus actually strove to use the metaphors of fire, water, and many other things to try to capture the idea of the cosmos as a domain of radical transformation and flow, in which not only does nothing stay what it is eternally but also nothing is what it appears when you look below the surface, that everything that seems even briefly static is only kept that way temporarily through the intense dynamism of shifting, contesting cosmic forces.

Twenty-five hundred years of progress have not made any easier the difficulty Heraclitus experienced, the struggle to help people see past the sometimes static surfaces of things to understand the seething, roiling storm underneath. Even our very language works against us, as we find comfortable and therefore readily adopt terms like status quo that reinforce our attachment to the illusion of stasis while resisting terms like fluxus quo that might be the keys to unlocking our ability to see things as they truly are.

My first exposure to this term was in the summer of 1999 when I read a philosophical column in a magazine. Here was the crucial paragraph for me, a concise statement that captures the Hellenic view of the cosmos as a realm of change:

Nature is understood in at least two profound senses, becoming and intrinsic validity, which to the Greeks are equivocally the same. The first sense of nature, as physis—"becoming," "growing," the gerundive or process-form of the verb phuo—describes the domain of relentless, tidal mutation: nature is the realm of all things generated and perishable where nothing can remain simply what it is (we have our word "nature" out of Latin as Cicero's invention, by analogy with physis, from the past participle of the verb nascere, natus = having been born). All natural existence is pregnant with its other, incubating cryptic forms of future order and orientation which are presently unthinkable: to exist in nature is to be variable and subvertible—all that is natural changes, falls prey to the fate of alliosis or "othering." All of natural existence is thus in motion, on the way from one state into another: Heraclitus' incisive dictum Panta rhei—All things flow—captures for all time the quintessence of ancient dynamism: the world as "fluxus quo."

——from "End Times: Millennia in Microcosm, Ancient Civilization Part 1: Nature as Becoming and as Intrinsic Truth" (Kenneth Smith, originally written 15 February 1997, published in The Comics Journal #215, August 1999)

Like most reasonably educated people, I knew the term flux, certainly in two senses from the Oxford Dictionary of the English Language—(1) the action of flowing, and (2) a continuous succession of changes of condition, composition, or substance—but when I read Smith's definition of fluxus quo above it was a revelation.

Here, I thought, was a term we badly needed in English, a term that in a nutshell captured an essential but hidden truth about the cosmos, a term that was especially vital for understanding the VISTA software lifecycle. Eventually I came to understand that it was not just VISTA but all medical informatics that were driven by the principle described by this term. The practice of medicine continually changes and flows as our understanding of it improves, so medical software, too, has to continually change and flow.

Where status quo is best understood as things being the way they are because they are standing still, fluxus quo describes things as being the way they are because they are changing.

The best way, though, to understand this or any other cosmic principle is not through a description of it, since principles are not things, but through a description of what it does, how it acts, how it changes the world, because principles are agents of change that generate patterns of flow in the cosmos.

So what about fluxus quo, the principle underlying all other principles? How does it work?

Yours truly,
Rick

What is Status Quo?

2010-02-04T16:53:00.000-08:00

Dear Reader,

The philosopher Plato did two-thousand-plus years of damage with his attractive but ultimately false view of the cosmos, and medical informatics suffers from his philosophy even today.

Plato was not comfortable with changes. He felt that a cosmos in eternal flux could not be comprehended. He wanted a world of fixed, stable, enduring ideas that could be used as a frame of reference, so he postulated the idea that change is an illusion, a mere flickering of shadows on the walls of the human cave, and the truth is fixed, eternal, unchanging—indeed, that the true cosmos is made of eternal unchanging ideas that are casting these shadows.

It's all very pretty and vivid but utterly false. The man was more poet than philosopher, in the end, and all his philosophies suffer from holding more beauty than truth (apologies to Mr. Keats).

Plato was not the first to try to bury his head in the sand - Parmenides before him had even more radically denied the existence of change and asserted that all is one and unchanging in defiance of the evidence of our senses - but it was Plato who developed the philosophy of stasis in the form that continues to trip us up today.

The problem with Plato's ideas is that they are an attractive nuisance. Any idiot can see change all around them all the time, but when someone is under the right kinds of pressure the rejection of change can be extraordinarily attractive.

Project managers, for example.

When you are being battered from every side to meet a deadline, the desire to pin down your targets to create a fixed frame of reference for managing the chaos can be overwhelming. In this way, most project managers become neo-Platonists, struggling against change.

The Oxford Dictionary of the English Language defines status quo as The existing state of affairs, a definition that is expressed in Platonic terms because it obscures the underlying principle unconsciously assumed to be at work by those who speak of a status quo: stasis.

status and stasis both derive from the same Latin/Greek root sta-, meaning to stand, as in to stand still, to hold, to be where and what you are in an unchanging fashion. You see, status quo seems to be a neutral phrase meaning "the way things are" because we ourselves are immersed in the philosophy of stasis—we take it for granted—and so cannot perceive that it really means "the way things are because they are standing still," that is, when things are the way they are because they are unchanging.

The extensive influence of mathematics in our education—which was advocated by Plato, by the way—exposes us deeply to simplistic math, the mathematics of is, of A equals A and A does not equal not-A, but cuts most of us off before we ever get into the mathematics of flow and change and flux from calculus on. We come to have a taken-for-granted worldview that understands a Newtonian and Cartesian fixed, mechanical universe far more easily than we can grasp the flow and flux of relativity and quantum physics because our math never went that far. Therefore, however much we may have thought we hated or resisted math in school, we pick up there and from the culture at large that the idea of a cosmos in which things are what they are and not what they're not just makes more sense than a cosmos in which everything is in continual flux.

The proof?

When under pressure, most of us seek security in some kind of fixed safety rather than by immersing ourselves more deeply into the flow of life. Stasis just feels safer to us, when push comes to shove. It feels more safe, more right, more natural, more real, more true.

So when we become project managers, we design our projects around fixed targets and seek to fight change to arrive at our fixed destinations. We are mercenaries who sell our services for money, and our services are that we promise to deliver a desirable fixed state by breaking down the gap between here and there into a series of manageable quantum steps. And at the end, we promise that the client will have been shifted into the new state they desire, they will have the things they want.

They will have a new status quo.

Too bad it's all a delusion, because Heraclitus was right: panta rhei, that is, everything flows.

Which brings us to the point of this series of essays: what is fluxus quo?

Yours truly,
Rick

It's the Culture, Stupid!

2010-01-14T20:43:00.000-08:00

Dear Reader,

ACPE’s 2004 Technology Survey identified one bright spot in the health IT industry: the U.S. Department of Veterans Affairs’s VISTA system (Veterans Health Information Systems and Technology Architecture). VISTA has an unusually high user-approval rate, has won Harvard’s Innovations in American Government Award, and has dramatically and measurably improved the quality of healthcare at VA facilities over the last quarter century. When Hurricane Katrina devastated New Orleans, the only medical records to survive were those in the VISTA system at the Veterans Affairs hospital; VISTA was back online after only forty-eight hours of downtime.

Because VISTA is not only a high-quality health IT system but also a public-domain one, it is increasingly being adopted outside VA. The national health IT movement’s increasing awareness of the importance of IT is contributing to VISTA’s rising popularity both in America and abroad, which is coalescing into an international VISTA movement.

VISTA is not only an unusually successful software product but also an unusual health IT software-development culture that grew from an analysis of not only why most health IT projects fail so often but also why VISTA projects tend to succeed.

This same analysis explains why VISTA is an unusual success story for health IT: it is developed according to an alternative software-development culture that fits the needs of medical culture better because it essentially is the medical culture. VISTA is developed by a community of programmers most of whom began their careers as doctors, pharmacists, lab techs, or other medical professionals. Not only were they not steeped in the stasis-seeking software-development culture, they were steeped in the medical culture, which is used to a continuous state of changing needs.

Accordingly, the alternative software-development culture they created does not seek to achieve a perfect status quo but instead a highly responsive fluxus quo to keep up with the pace of medical change. Instead of seeking to avoid errors, this approach seeks to fix them quickly, something that would be impossible under the staggering quality-assurance (QA) overhead of the dominant paradigm.

Most importantly, in healthcare the stakes are too high to measure software correctness any way except by how well it meets the current state of medical needs; instead of measuring correctness by adherence to specifications this approach measures it by user satisfaction. Since medicine is far too complex for any individual or small body to authoritatively define, authority over what is to be done to the software is put in the hands of all of the users and the developers are given the authority to make whatever changes they need to whenever they need to in order to please their users. In short, authority is decentralized and the future of the software resides in the hands of an ongoing collaboration between the health professionals who use VISTA and the software engineers who develop it for them.

To allow the customization and peer review required in medicine, the source code for VISTA is open and the software itself is free. To avoid imposing any kind of penalty on efforts to make the software better serve medicine, adopters are not charged any kind of fees to report problems or have them fixed, nor are they charged to have improvements made. The economic model is instead (1) fee-for-service to set up a new VISTA site and train its adopters in how to use it, and (2) fee-for-relationship for ongoing support to encourage adopters to make as much use of support as possible, the better to channel their insights into the software development lifecycle.

In these and many other ways, the VISTA software-development culture is essentially the opposite of the dominant paradigm. It has more in common with more recent upstart methodologies like the open-source movement, rapid prototyping, agile programming, extreme programming, and so on, though it has been doing these and many other highly unusual things since long before any of these new methdologies had names.

The upshot of this VISTA analysis of the state of health IT can be summed up as follows.

Even if a perfect health IT solution were installed at a hospital, if the dominant software methodology is followed that software will become less and less able to meet the needs of its adopters as the state of medicine shifts out from under it until it eventually becomes a threat to the health of its patients. That is, good health IT software goes bad over time under the dominant software-development culture. Likewise, even if a dreadful health IT solution were installed at a hospital, if the VISTA software methodology is followed that software will become more and more able to meet the needs of its adopters and will change to take into account advances in the state of medical science. That is, bad IT software turns good over time under the VISTA software-development culture.

Yours truly,
Rick

Status Quo Kills

2009-12-31T00:01:00.000-08:00

Dear Reader,

Most health IT projects fail because the software industry’s dominant response to the software crisis precisely collides with the unique demands of health IT.

Ever since Edsger Dijkstra began theorizing about how to solve the software crisis in 1972, computer science has focused understandably on the need to drive down the rate of errors in order to produce correct code. This focus on reducing errors has led to a focus on careful specifications and the careful coding designed to measurably meet those specifications. Under this paradigm, which is taught in all computer science departments across the country and followed by the software industry, success is defined as adherence to a software specification and errors as deviations from that specification. This error-avoidance philosophy is so ubiquitous, it is even implicit in the success and failure critieria used by The Standish Group in its CHAOS reports.

The resulting software-development process drives toward achieving the fixed goal of compliance with the specification, toward achieving a kind of crystalline, static perfection. That is, for the software-development process to avoid errors as much as possible, it has to impose extensive testing on all changes, which raises the cost and time required to make changes, which has the effect of discouraging changes. Indeed, everything about the dominant software paradigm rewards compliance with specifications and punishes attempts to modify the specification, especially in mid-course. It is a specification-driven, stasis-seeking methodology hostile to change. It dominates the software industry, including those companies engaged in producing health IT.

The problem with trying to apply such a model to healthcare is twofold.

First, healthcare is extraordinarily complex, essentially impossible to capture in a specification, which guarantees that any specification will deviate from the actual needs of the users. When faced with a choice between a clear specification and ambiguous statements of need, the specification-driven, stasis-seeking paradigm will always choose the specification over reality.

Second, even if it were possible to capture a perfect specification of the needs of health IT adopters, medicine changes continuously in response to the continuous scientific investigation into health and the resulting continuous stream of new discoveries that impact best practices. Hence, even a correct specification would become increasingly incorrect merely through the passage of time.

Healthcare is thus the worst possible case for the dominant software paradigm: an unspecifiably complex problem domain that continuously changes.

Unfortunately, health IT vendors have two overpowering incentives to disregard this fundamental mismatch of their approach and their subject.

First, the logic of avoiding errors seems irresistable, particularly so when backed by the consensus of an entire industry and its corresponding field of science; when struggling to gain control over out-of-control software projects, the retreat to controlling errors intuitively feels like the right move.

Second, the status quo is very, very profitable, especially because of the mismatch with the needs of healthcare. To help discourage changes to the specification in mid-course, it is standard procedure for IT companies to charge exorbitant premiums for such mid-course spec changes. The mismatch between health IT specifications and real healthcare information needs guarantees that health IT projects will involve a great many changes to the specification, for each of which the health IT vendor will earn a premium. The cost overruns that health IT adopters lament are the profits that keep health IT vendors in business.

In short, when applied to healthcare the dominant specification-driven, stasis-seeking, error-phobic software-development culture kills, but it does so both profitably and untraceably.

Yours truly,
Rick

Postscript: Let no one—no one—infer from this posting that I have anything less than respect and admiration for the great Edsger Dijkstra. My argument is that automating rapidly changing fields like medicine is a special case in which Dijkstra's prescription is not the best solution for addressing Dijkstra's concerns.

The Risks of Health Information Technology

2009-12-30T21:42:00.000-08:00

Dear Reader,

Health IT success or failure numbers are very hard to come by, in part because some healthcare IT vendors require their customers to sign contracts banning them from publicly discussing the success or failure of their health IT, in part because the legal stakes are much, much higher with health IT failures which creates a disincentive to be forthcoming about dramatic failures.

Most numbers therefore are anecdotal. For example, the American College of Physician Executives (ACPE) surveyed its thousand members in its 2004 Technology Survey, and the results suggested that even successful health IT projects are often more expensive and less useful than expected, often permanently reducing physician productivity.

Informal surveys of non-management medical professionals at hospitals adopting IT reveal a much lower rate of satisfaction than that reported by those in management positions. The most frequent complaints are (1) a poor fit between the software’s design and the needs of its users, (2) poor responsiveness to requests to improve the software, and (3) hidden and horrendous costs that emerge in IT adoption during the process of trying to get badly fitting software changed to truly meet the needs of its users.

Off the record health IT programmers are often surprisingly candid about how bad their software is and about how resistant health IT company management is to making unprofitable changes that would improve its quality. Producing bad health IT software has been very profitable for a long time.

Health IT is the industry that results when one industry in crisis attempts to assist another industry in crisis, creating a collision of crises. The emergence of an American health IT movement is an important step toward improving health in this country, but unless the true state of health IT is understood and dealt with it will almost certainly be a very painful step indeed.

Yours truly,
Rick

The Risks of Information Technology

2009-12-29T21:21:00.000-08:00

Dear Reader,

Unfortunately, missing from all this discussion is an appreciation of the dark side of health IT. Unless the problems with American health IT are as openly discussed, understood, and dealt with, as the problems with American healthcare, mixing IT with healthcare could deepen our national healthcare crisis.

The problems with health IT begin with IT itself. According to The Standish Group’s CHAOS 2004 survey results, only 29% of software projects come in on time, on budget, and with all the features originally planned. 53% of software projects fail at least partially, and 18% fail completely. Although people not familiar with the sorry state of the software industry find these numbers shocking, the reality is even worse.

The Standish Group’s numbers are oriented toward tracking the effectiveness of the project management, not the effectiveness of the resulting software. Any experienced IT user can tell you that many “successful” projects are actually failures from a usefulness perspective, bad ideas successfully imposed upon the organization. Similarly, these numbers do not factor in whether the budget was an effective use of the organization’s resources. Many, many projects are vastly more expensive than they should be for the value delivered. Once these crucial but omitted criteria are imposed on the CHAOS numbers, the numbers fall in line with the reality of an industry in crisis, The Software Crisis.

Since 1968, the software industry has understood itself to be immired in a crisis that defies solution. Forty years of innovation have still not managed to fix the kinds of problems measured by The Standish Group. Indeed, they have only clarified that at the root of the problem is a basic but paradoxical principle of complexity: Success breeds failure. Success with software development invariably increases the amount of software to be managed and taken into account in the next round of development. There is no limit to the potential complexity of software, but human capacity for managing complexity begins to fall apart at surprisingly low levels of complexity.

Successful software lifecycles become less successful over time. No wonder so many software adopters cyclically opt to replace what they have with something new! The temptation to blame the current software and start over with something else helps to fuel a major portion of the healthcare IT industry’s annual revenues. This wheel spinning may be successfully executed as projects and reported as such in the CHAOS reports, but it constitutes ongoing waste and failure disguised as success.

The consequences of our limitations are starkly illustrated by two parallel trends. First, at the same time that the hardware revolution has made computer hardware orders of magnitude smaller, faster, and cheaper, the software crisis has made software orders of magnitude larger, slower and more expensive. Second, the ability to succeed with software projects goes down dramatically as the scale of those projects increases, a factor noted in the CHAOS reports.

Yours truly,
Rick

The Importance of Health Information Technology

2009-12-28T19:10:00.000-08:00

Dear Reader,

American healthcare is in crisis. It has been in crisis for decades, but thanks to the Institute of Medicine (IOM)’s Committee on the Quality of Health Care in America we can finally discuss it openly and objectively.

The committee’s reports—To Err is Human: Building a Safer Health System and Crossing the Quality Chasm: A New Health System for the 21st Century—have changed history by ending forever the viability of our industry’s de facto strategy of denying the problem. These landmark reports have also given us a framework for understanding the nature of the problems we face and the broad structure of the solutions we have to create and bring to bear to improve healthcare in America.

In Crossing the Quality Chasm, one of the IOM’s prescriptions for improving American healthcare is the use of information technology (IT): “IT has enormous potential to improve the quality of health care with regard to all six of the aims set forth in Chapter 2.” Indeed, the report’s ninth recommendation reads:

Congress, the executive branch, leaders of health care organizations, public and private purchasers, and health informatics associations and vendors should make a renewed national commitment to building an information infrastructure to support health care delivery, consumer health, quality measurement and improvement, public accountability, clinical and health services research, and clinical education. This commitment should lead to the elimination of most handwritten clinical data by the end of the decade.

This recommendation has launched a national discussion of the importance of health IT and strengthened the arguments of health IT advocates. Where health IT was once a technical topic of limited interest, it is now understood to be an essential component of our national strategy for improving healthcare. For example, the Commonwealth Fund’s 2003 Annual Report, Achieving a High-Performance Health System, uses language very similar to IOM’s in the report’s step four toward building a truly high-performance health system:

Invest in health information technology. Other countries are quickly surpassing the United States in adopting electronic medical records and prescribing systems. Their governments have invested in infrastructure and established the necessary standards, and the United States needs to do the same.

Increasing state and federal interest, funding, and mandates for health IT are symptoms of what has become a national health IT movement, much of which was catalyzed by the IOM’s reports. After all these years, there is a growing national consensus about the potential of IT to improve healthcare and a growing political will to do something about it.

Yours truly,
Rick

Fluxus Quo: A New Series

2009-12-27T18:06:00.000-08:00

Dear Reader,

At Rodney Kay's request, let's postpone the continuing discussion of master planning in favor of what I agree is a long overdue topic for understanding VISTA and organic order: fluxus quo.

Since information out of context is noise, let's first explore how fluxus quo applies to health information technology (IT), to make clear why we care. Over the next few weeks, we'll run through a draft chapter of the book I'm writing on the VISTA lifecycle. This chapter makes the VISTA community's central argument about what's wrong with health IT and how to fix it. Fluxus quo is both the problem and the solution.

Yours truly,
Rick

Interlude: Horatio Smith on Shelley's Ozymandias

2009-12-13T14:05:00.000-08:00

OZYMANDIAS
or
ON A STUPENDOUS LEG OF GRANITE, DISCOVERED STANDING BY ITSELF IN THE DESERTS OF EGYPT, WITH THE INSCRIPTION INSERTED BELOW

In Egypt's sandy silence, all alone,
Stands a gigantic Leg, which far off throws
The only shadow that the Desert knows:
"I am great OZYMANDIAS," saith the stone,
"The King of Kings; this mighty City shows
"The wonders of my hand." The City's gone,
Nought but the Leg remaining to disclose
The site of this forgotten Babylon.
We wonder, and some Hunter may express
Wonder like ours, when thro' the wilderness
Where London stood, holding the Wolf in chace,
He meets some fragments huge, and stops to guess
What powerful but unrecorded race
Once dwelt in that annihilated place.

The Principle of Organic Order: Our Journey So Far

2009-11-24T08:39:00.000-08:00

Dear Reader,

Let's resume our quest to understand the VISTA software lifecycle by continuing our exploration of Christopher Alexander's small masterpiece, The Oregon Experiment. In this book he describes how architectural design used to be organized according to a timeless way of building called organic development and describes the problems that have accumulated in modern architecture as a result of abandoning it. Organic development is the same powerful process harnessed in the classic VISTA software lifecycle. Since the VISTA lifecycle's never been adequately described in writing, we're trying to understand it by reviewing Alexander's description of organic development and by comparing and contrasting it with VISTA's model.

Alexander describes organic development in terms of six principles, with a chapter on each. When we left off in September, we were in chapter one, which describes the Principle of Organic Order. Alexander summarizes this principle as:

Planning and construction will be guided by a process which allows the whole to emerge gradually from local acts.

To illustrate the importance of this principle, Alexander explores the nature of the modern architectural-planning process, in which planners imagine the problem of creating good architecture boils down to a struggle between chaos and order in which their job is to impose order (a vision, an aesthetic, a design) on an otherwise chaotic situation. Planners' main tool in this battle is the modern master plan, which attempts to fix in advance the more-or-less complete solution to the problems they've been hired to solve.

Alexander demonstrates that master plans themselves are deeply problematic, because in good architectural design there's a far more important quality at work than either order or chaos, what he calls organic order. Master plans by their very nature drive organic order out of a project because they're oblivious to it. As long as planners try to reduce their mission to a struggle between two choices, order and chaos, they'll remain unable to understand the damage they do with their master plans, because they'll only look for the elimination of chaos, the creation of order, and call that successful - even though the form of order they create causes worse problems than the chaos they've eliminated.

As with architecture, so with enterprise-scale software-development projects: the creation of a master plan is the first major milestone of any serious project, and the plan remains the fundamental organizing tool for everything that follows. To accuse master plans of being the root problem in modern architecture (or software engineering) is a radical act. It demands more than accusations, so Alexander supports his claim by examining the essential strengths and weaknesses of all master plans, to show that the problems they cause can't be avoided without abandoning this entire approach to planning.

In our review chapter one, we began by exploring the problem of chaos. Although chaotic situations do spontaneously generate forms of order, they also spontaneously generate forms of disorder, and the conflict between the two ensures that chaotically generated order cannot remain stable over long periods of time and also cannot create higher forms of order. For something as complex as medicine with stakes as high as life or death, master planners are right to reject chaotic order as a source of organization for software architecture. The fundamental strength of master plans is that they provide an alternative to chaotic order.

Their fundamental weakness is that in its place they impose totalitarian order, which is essentially hostile to organic order, so we next began reviewing the four unavoidable problems of master plans described by Alexander.

First, master plans are too precise about their solutions. They deal with unknowns by false prophecy, by trying to project a detailed picture of the future. They do this in part because their focus isn't on understanding the problem; it's on selling a solution, and to do that they have to paint a bold, emotionally compelling picture to win the contract. The buyers contribute to this because they're uncomfortable with the inescapable uncertainties at the beginning of any project, so they demand a false clarity to comfort them and give them enough confidence to proceed. The many details fixed in the master plan lend it persuasiveness, verisimilitude, but not truth. Later in the project those same details will tear the project apart as they collide with reality in precise and (only from the perspective of hindsight) predictable ways.

Second, master plans are too imprecise about the problems they mean to solve. As any experienced builder or programmer will tell you, only after you solve a problem do you fully understand it. The process of construction creates a flow of discoveries about the nature of the problems we face, surprises that reveal the many ways we're wrong about what we have to overcome to succeed. We know the most about the overall problem at the end, but master plans are created at the beginning, thus locking in the maximum amount of ignorance about those problems. Master plans propose solutions to problems the participants will never again understand so poorly.

Next we'll explore the third problem, alienation.

Yours truly,
Rick

Interlude: Do the Right Thing

2009-10-01T22:40:00.000-07:00

Dear Reader,

Do you want VISTA to succeed, to help us drive medical error out of the top five killers in America? Here are seven steps to make that much more likely:

1) Cancel every VISTA-replacement project going on in the VA and never fund another.

2) Reassemble the primary package-development teams and resume the traditional cycles of rapid patch development and regular releases of new versions of all packages. That lifecycle made VISTA great; violating it crippled VISTA in the DOD, and is crippling it in VA. Put authority over the software back in the programmers' hands and leave it there; they know more about what's possible than you do.

3) Reorganize VA to put the majority of programmers back to work for local hospitals and regional networks. Put authority over the hospital computer systems back in the hands of hospitals and local networks; they know more about how to make VISTA serve their hospitals than you do.

4) Invest heavily in training up a new generation of VISTA experts. This is the second most important item on this list, just behind the next one:

5) Let users' requests for bug fixes and enhancements directly drive all VISTA development. Put authority over development priorities back in the users' hands and leave it there; they know more about what they need than you do.

6) Gut the Clinger Cohen Act so VA and IHS can do the right thing and invest in the people they need instead of being forced to outsource all their expertise and capabilities. The Clinger Cohen Act requires VA and other federal agencies to strangle themselves, which they've been working on doing since 1996. The results speak for themselves.

7) Invest heavily in rebuilding the tattered support community VISTA had before VA shredded it in the mid 90s, the support community the VA needs and cannot thrive without. VA needs to give up its siege mentality, needs to tear down the iron curtain it has built between itself and the rest of the world and start really collaborating with other VISTA organizations, beginning with IHS. Terrorists are not assaulting the VA, and VA's own VISTA experts are not the enemy; VA needs to spend less time and money investigating its VISTA experts for possible "collaboration without permission" and instead seek out and invest in opportunities to work together with others. Having frustrated, insulted, and driven away half of its top-tier VISTA expertise, VA will never again be the sole arbiter of VISTA's future. VA will never again be in a position to do as much damage to VISTA as it did over the last fifteen years. But if VA does all of the right things, if for example it does these seven things among many others, then VA could become a good VISTA organization again, instead of a hostile organization where good VISTA professionals sacrifice and struggle to do the right thing even though they know they may well be punished for it.

I'm hopeful about new VA CIO Roger Baker, but I'm looking for more than hope. It will be easy to measure whether he can fulfill the promise of his good words and good intentions, because deeply experienced VISTA hardhats know what he needs to do to turn things around.

"It's the thought that counts" is a pleasant thought, but in the end what matters is that we find a way to do the right thing. You're not in the dark. You're not lost. You're surrounded by people who know what you need to do to succeed with VISTA. Listen to them. Help them help you to do the right thing.

Yours truly,
Rick

Interlude: Shelley on Hybris

2009-09-17T01:14:00.000-07:00

OZYMANDIAS

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desert. Near them on the sand,
Half sunk, a shatter'd visage lies, whose frown
And wrinkled lip and sneer of cold command
Tell that its sculptor well those passions read
Which yet survive, stamp'd on these lifeless things,
The hand that mock'd them and the heart that fed.
And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.

Four Problems with Master Plans: (2) Imprecision

2009-09-16T23:59:00.000-07:00

Dear Reader,

Yes, after the first criticism this second one doesn't seem fair, but it's true. Life, which isn't a logical syllogism, is filled with seeming contradictions. Here's one: not only are master plans too precise, paradoxically they also aren't precise enough.

Specifically while they're too precise about what the future solutions should look like, they're far too vague about the nature of the problems they're supposed to solve. As a result, even in theory master plans only address some parts of the problem and not others.

This is bad but understandable.

Master plans can't possibly identify, let alone address, the full scope of the problems they're supposed to solve because they're created at the beginning, before any serious effort has been made to solve the problem, and thus before Murphy's Law has had its hundreds of chances to teach us how wrong we are about the full extent of the problem. At the time we write a master plan, we just don't know enough about the problem to get its details clear in our heads, and without those details we can't really solve the problem, only take a clumsy swipe at it.

This is understandable but bad.

How bad?

Sometimes it's inconvenient.

Maybe while planning your day, you fail to pay attention to what you're doing at the moment and lock your keys in the car, thus ruining your plans.

Maybe to save three million dollars you replace a deep, stiff bridge design that lets the wind pass through it with a cheaper, shallower, more flexible one that makes the wind pass over and under it, creating aerodynamic lift so it flutters in the wind, tears itself apart, and collapses into the deeps.

Maybe you overplan your bombing runs by putting precisely the right amount of gas in the planes for them to fly out, bomb their targets, and return, but then they encounter a headwind that makes them burn up extra gas so they drop out of the skies before returning home, forcing the pilots to parachute to safety.

Sometimes it's catastrophic.

Maybe you use an explosive gas for airship buoyancy and then try to control all the many scenarios that could cause it to ignite, only to discover that sooner or later your planning or control slips, killing thirty-six people.

Maybe it seems inconvenient to standardize your fire-hose couplings, so you don't, so when your city catches fire the fire engines from neighboring cities arrive only to find they can't help you, and your city burns to the ground.

Maybe your regulations only require a total lifeboat capacity of 1,178 people, even though your ship can carry 3,547, causing the deaths of 1,517 people.

Details matter.

It is the details of problems that make them problems. Something as small as an O-ring seal can kill you if you get it wrong. Engineering is the discipline where Don't sweat the small stuff is a recipe for disaster (and where . . . and it's all small stuff is criminal negligence).

In medical informatics, more starkly obvious than in much of life, the problems we face seem to shift when we discover their nature is different than we at first thought, and they also actually shift as the nature of medicine and software shift around us. The details of our solutions have to be able to shift along with the problems or we can't solve them.

Master plans prevent that dance of solutions with problems in four ways.

First, they emphasize the big picture over the details, wasting energy on prophecy that should have been spent on understanding the problems better, so the necessary details of the solution are missing or vague.

Second, what details they do specify are shaped by design to create (i.e., to serve) the totality, not by discovery to actually solve the problems, so they tend to be out of sync with the reality of the problems (i.e., wrong).

Third, they rigidly lock in those details, preventing them from moving with the problems as the problems shift, soon making any accurate details outdated and incorrect.

Fourth, the nature and interactions of the problems we aim to solve are far too complex to capture in a plan to begin with, ensuring that no matter how much effort goes into a medical-informatics master plan, its worldview always ends up being a ridiculous cartoon of the situation it is meant to deal with.

Any one of these characteristics would be enough to cripple a master plan. Together, they create irresistible forces that cause all VISTA master plans to converge on the same brief lifecycle of (1) ballyhoo, (2) bogging down, and (3) breakdown. And yet the inevitability of failure evidently can't compete with the intoxicating feeling of control a master plan creates, judging by the relentless parade of VISTA-replacement (or "modernization") boondoggles. It would be tragic if after fifteen years it weren't so drearily risible.

Still, at least we can serve as an object lesson to validate Alexander's point:

Master plans fit the shape of the problems with too little precision, and so they fail.

Yours truly,
Rick

Postscript: And so, Alexander's critique of architectural master plans holds even more true for enterprise-scale medical-informatics than it does for architecture: Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough. It fails because each part hinges on a conception of a "totality," which cannot respond to the inevitable accidents of time and still maintain its order. And it fails because as a result of its rigidity, it cannot afford to guide the details around the buildings which really matter; if drawn in detail, these details would be absurdly rigid.

Interlude: Why Some People Just Don't See It

2009-09-15T21:29:00.000-07:00

Dear Reader,

In response to my post on 30 August 2009, "Principle 1: Organic Order, part 1: The Three Kinds of Order", on August 31, 2009 at 6:58 AM Die Anyway wrote:

're:"...it's precisely because VA turned away from those processes toward more totalitarian ones that it lost the ability to effectively manage or develop VISTA."

'I see it and you see it so why don't the ivory-tower, pointy-hairs see it? Or do they see it and ignore it because they have an entirely different agenda?

'In any case, as a biologist and programmer I like the idea of organic design even if it did originate in those pre-historic times of the mid '70s.

'Eat well, stay fit, die anyway!'

My answer doesn't fit within a blogger comment, so I'll reply here, as this post:

Dear Die Anyway,

The VISTA managers in VA who try to overly centralize and control VISTA, i.e., who try to impose totalitarian rather than organic order, (1) are not necessarily the majority, just the most powerful or in-favor managers (I know some good VISTA supervisors and managers in the VA and elsewhere), and (2) they do not see what we see because they lack the proper understanding of their context.

They think they're facing an entirely different kind of problem than they actually are. If you interpret their actions from the standpoint of their worldview, their approach makes sense for a while. As we'll explore later in this weblog, their approach leads to a gradually increasing breakdown that eventually becomes so dire that even they can see things aren't working. By then they're usually too burned out and despondent to be capable of taking responsibility for their actions by steering the organization in a healthier direction. There's a certain amount of morale a manager has to have to be effective, and unfortunately when one is committed to a false idea one tends to use up one's effective energies on the dead ends.

The problem with the actual cosmos is that its forces and principles are subtle, easily overlooked. Any reductionist intellectual can mentally reduce an intricate organic system to a trivial mechanical one. When one is tasked with something impossible, like managing VISTA while pleasing Congress, one's mind finds otherwise implausible oversimplifications oddly irresistible, because they offer a desperately needed false hope.

Once people decide on an interpretation of reality, they have an astonishing ability to see every "fact" that confirms that interpretation, and an equally astonishing ability not to see everything else that disproves that interpretation. To the outside observer this seems to result in irrational behavior, but from within the interpreter's reality bubble, within the framework of interpretations, the behavior may be completely rational, even inevitable.

It is a great disappointment to discover that rationality has been overhyped. Reason can be used to reach the falsest or vilest conclusions through irresistible logic drawn from false premises.

Rationality is worthless, even dangerous, unless it is harnessed to two things grossly undervalued - even invisible - in our culture:

(1) profound insight into the essential principles at work in creating each situation, and

(2) mature, discriminating taste capable of balancing priorities among competing values to figure out which good must give way for which other good.

Insight is vital because the truth of hardly any situation is visible on the surface, but instead must be sought in the nuanced and subtle but powerful forces that create that surface.

Taste is vital because contrary to just about everything we teach through schools, the arts, and common sense, the bad things in the world do not result from a great conflict between good and evil, but from conflicts between various goods.

Values conflict, which the classical Greeks knew but which we do not, and which good deserves priority over the others shifts and flows from situation to situation depending on the hidden forces at work.

Neither the truth about the source of problems nor the two vital qualities needed to deal with that truth end up in position descriptions, evaluation criteria, or the law. Instead, managers inside the government and out are held to simple-minded, mechanical criteria, and if they do not bend themselves to fit those laws, criteria, and requirements then they cannot thrive in their careers. They have to believe what they're doing is right, so they do.

In short, I think the answer to your important question is answered best by Upton Sinclair:

"It is difficult to get a man to understand something when his job depends on not understanding it."

Part of why I love biology is that it is difficult to explain in simplistic mechanistic terms, so its study tends to compel you to develop an appreciation of deeper, essential principles.

Thank you for your comments.

Yours truly,
Rick

Four Problems with Master Plans: (1) Precision

2009-09-01T20:43:00.000-07:00

Dear Reader,

It is simply not possible to fix today what the environment should be like twenty years from today, and then to steer the piecemeal process of development toward that fixed, imaginary world.

This escapes us when we agree to create a master plan. We forget the simple truth that we're not gods or prophets; predicting the future is never our forte but often our downfall.

Our grand designs fail in four ways.

Today we discuss the first: a master plan is too precise. By predicting the precise shape of the future - the following buildings or software modules will be built in the following ways, and will contribute to the design like so - it leads us into precise collisions with reality when some parts of the plan prove impossible, as always happens.

Murphy's Law isn't very funny to software engineers; it's the reality under which we operate, a reality that's too easy to ignore during planning but impossible to ignore later when our designs come crashing down around all our heads at great expense.

VISTA programming is designed to take advantage of Murphy's Law. It's a highly adaptive process in which we immerse ourselves in the problem with our adopters as guides, in which we do not set out to predict the future, only to solve some specific, immediate problem. A nonprogrammer simply cannot imagine how much failure is involved before one achieves success, but that string of failures is why the VISTA model works and master planning doesn't.

By making planning a cumbersome, expensive process that comes at the beginning, before Murphy's Law has taught us the many ways we're wrong about what's possible, master planning builds a profound ignorance about what's possible into the development process from the start. It saves the exposure of all its failures for the end, when the differences between what's possible and what the plan proposes finally accumulate so greatly that everything collapses in a great crash. Ironically, it's the act of struggling to preserve the plan's success that increases the scale of the failure, since covering up problems and investing more time and money help intensify the inevitable collapse.

By contrast, the VISTA methodology begins making mistakes up front, one at a time, while they're still small - a string of little crashes. We continue making mistakes the whole way, from beginning to end, but they remain small because (1) there is no big, expensive investment in a master plan to try to protect so we can and do change directions repeatedly, (2) the future user of the software is sitting right there the whole time saying "No, we can't do it like that," and (3) instead of struggling to adhere to an increasingly irrelevant plan the team is building up a map of the terrain of the project, a practical guide to many different ways to succeed or fail.

The contrast is stark. Master plans are prophecies. VISTA plans are histories. Master plans are expensive, produced separately from the software. VISTA plans are cheap, produced alongside the software. Master plans are written and finished at the beginning, when we know as little as possible about the problems and its solution. VISTA plans are written during programming and not finished until the end, when we know as much as possible about what didn't work and what did.

The excessive precision of a master plan comes from its focus on the solution, which means trying to pin down the future. VISTA plans avoid that by focusing on understanding the problem and letting the solution emerge gradually and often unexpectedly.

That is, in the master-planning approach we create the illusion of knowing where we're going without first really understanding the nature of the problems we claim to be solving. In the VISTA planning approach, we acknowledge from the start that we have only a vague idea where we're going, only that we know we're going to solve a specific problem by getting to know it very well.

The VISTA approach involves a lot of false starts and backtracking, a lot of mistakes - it looks sloppy and loose compared to the professionalism of a master plan - but that's its strength and the weakness of a master plan.

The VISTA methodology was first advocated by John D. Chase, Jack Brooks, and Ted O'Neill. Here's what Ted O'Neill and Marty Johnson had to say about the difference between the master-planning approach and their own, in their memo to Ken Dickie back on June 10, 1981:

Requirement specifications can be derived effectively and quickly by developing a basic functioning system with the intended user, then further refining the system through user-suggested modifications. The resulting system, in daily use, will provide a much more complete and accurate reflection of user requirements than any narrative description of a system that has not been built. Moreover, by using available modern techniques, such as natural language application generators, database management systems and other software tools, fully operational prototype systems can usually be produced more rapidly than can paper descriptions thereof. Requirement specifications that are produced before any prototype testing activity has been undertaken are now recognized by most computer professionals as inadequate.

Now go back and reread Alexander's quote from the top of this blog entry.

These are two different ways of saying the same thing. They have the same criticism of master plans, independently arrived at from two different perspectives. Our own history bears out the truth of this convergent revelation.

Master plans predict the shape of the future with too much precision, and so they fail.

Yours truly,
Rick

Postscript: Master planning isn't the only kind of planning. The Principle of Diagnosis involves a very different form of up-front planning that helps to create natural order instead of totalitarian order. There are also forms of community planning that focus on studying the problems communities face - the trends, developing problems, and so on - and then draw general, reasonable conclusions to help communities plan. Likewise, there are dynamic forms of project planning designed to accommodate the unpredictable path of research and development. Each of these approaches is the opposite of the master planning approach because they focus on what we can know best - the nature of our present and developing problems - and sketch lightly and prudently in recommending how and when those problems can be solved.

Principle 1: Organic Order: The Problem of Chaotic Order

2009-08-31T07:35:00.000-07:00

Dear Reader,

Chaos is not what most people think it is.

To begin with, I'm not using the mathematical term, which sweeps up areas of mathematics outside the traditional disciplines to show there's mathematical order beyond that we usually consider. Although an interesting subject, it's only metaphorically related to true organizational chaos. I'm using the other meaning for chaos: the results of a complete lack of planning, the outcome feared by planners and managers everywhere.

With that in mind, I must next emphasize that chaos isn't the absence of patterns. On the contrary, even fully random processes produce emergent patterns. That kind of patternless chaos people imagine actually takes quite a bit of planning and control to pull off. True chaos always generates two kinds of patterns: accidental and intrinsic.

First, even the chaotic results of random processes produce both statistical ones (like bell curves) and specific ones (like the constellations among the stars) as a normal and expected result of the lack of planning. These macro- and micro-patterns can be used as the seeds for future organization.

Second, when living things are involved (intelligent or otherwise), their needs drive them to produce nonrandom patterns of behavior and organization so they can live and thrive. Firstly, the forces within living things aren't random but instead will lead them to organize their lives in ways that meet their needs - like returning to rivers to drink (or to hunt the drinkers) on a regular schedule. Secondly, living things inhabit ecosystems whose powers and forces reward and punish their behavior, leading living things to adapt in common ways to common forces. For example, even such different life forms as fish, reptiles, and mammals will gradually evolve into the same shapes if they occupy the same ecological niches because the same forces will work upon them over their generations. This is why the tuna, the ichthyosaur, and the dolphin end up closely resembling each other despite very different origins - they converge on the only viable solution to the pressures they're under.

Advocates of imposed order usually underestimate the value of these forms of chaotic order. A great deal of useful order can be achieved without imposition, simply because of people's intrinsic need for order. For example, despite all the screaming and panicking shown in disaster movies, which help to train into us a terror of chaos and of other people (and an artificial craving for imposed leadership that is well understood by juntas when they execute their coups d'etat), during and after disasters people frequently organize themselves to help out family, friends, and neighbors, without any leadership at all - not always, but more often than fearmongers would have us believe.

Advocates of chaotic order, such as anarchists, point to this kind of natural collaboration and contrast it with the inevitable evils of totalitarian order to argue their position that any form of central organization is both unnecessary and unwanted. Anyone who's bothered to study Nazi Germany or Stalinist Russia, or who's thought long and hard about how readily republics loose their democratic bonds to become fascist empires, or who's observed how the disturbing trend toward decreasing personal freedom and privacy changes our culture more and more toward the dystopia of Orwell's novel 1984, has to give this position more than a moment's consideration. There are serious points raised by advocates of chaotic order, and we must do justice to those issues or suffer the consequences of those who fail to learn from history.

Nevertheless, I'm not persuaded, and you shouldn't be either.

There are two excellent reasons why chaotic order is not sufficient.

1) The order produced in chaotic systems is generally offset by the disorder also produced by chaotic systems. Without central coordination, some enclaves will self-organize into more or less peaceful communities, true, but others will devolve into internicine feuds (Internet flame-wars, anyone?), and still others will become predatory. Just as I'll not grant advocates of totalitarian order their insistence on the absence of order within chaos, so I'll also not grant the advocates of chaotic order the absence of destructive consequences.

2) Chaotic order is almost always local, almost never universal. That's enough to solve certain categories of problems but not others, not problems beyond a certain scale. As a VISTA theorist, I am particularly bothered by this reason, because the complete VISTA lifecycle requires that (a) a great number of specialists be given the time and focus needed to master their chosen parts of VISTA, (b) a large number of autonomous teams follow a common culture to ensure that what they produce is compatible, that it creates a living whole, and (c) people not only act with good intentions but also actually do the right thing, since lives and privacy are at stake. These things require more than local or temporary order. These requirements unfortunately fall into chaotic order's demonstrated weaknesses, making it a poor choice of approaches for developing VISTA.

But beyond two there is an even better third reason to reject it for VISTA: it is predicated on a false dilemma, namely that one must choose between totalitarian order and chaos, or some compromise between them. As Alexander argues and I'll explore in this weblog, natural order represents a superior alternative to either of these dysfunctional approaches.

That is, since we already have a model for a system of organic order for managing VISTA development, we don't need to pay the price of chaotic order's weaknesses in order to gain its benefits.

Nevertheless, we're going to return repeatedly to the subject of chaotic order, because in management terms (and now for the punchline) chaos is just a pejorative term for freedom, reflecting a deep unacknowledged terror in all of us. Until we examine our ambivalent relationship to freedom, any cost-benefit analysis of chaotic order is at best highly suspect.

Yours truly,
Rick

Interlude: Ordering The Oregon Experiment

2009-08-30T12:43:00.000-07:00

Dear Reader,

You can order a copy of The Oregon Experiment from your friendly neighborhood independent bookstore, or from any number of online book services, including:

A Libris
Abe Books
Amazon
Powell's

Yours truly,
Rick

Principle 1: Organic Order, part 1: The Three Kinds of Order

2009-08-30T11:22:00.000-07:00

Dear Reader,

Alexander diagnoses a nearly universal illness in our systems of architectural planning: we use master plans to try to guide our development, to plan for the future:

. . . master plans, are intended to coordinate the many hundreds of otherwise independent acts of building . . . to make sure . . . that the many acts of building in a community will together gradually help to create a whole, instead of merely making up an aggregation of unrelated parts, a chaos.

. . . the master plan, as currently conceived, cannot create a whole. It can create a totality, but not a whole. It can create totalitarian order, but not organic order . . . although the task of making sure that individual acts of building cooperate to form a whole is real, the conventional master plan - based on a map of the future - cannot possibly perform this task . . . because it is too rigid to do so - and because, in addition, it creates an entirely new set of other problems, more devastating in human terms than the chaos it is meant to govern.

It's not enough to replace chaos with order. Order can be worse than chaos.

The problem with chaos is that the "whole" (really just a collection) is less than the sum of the parts. The entire reason for planning is to do better than this, but master plans only give us chaos's opposite: totalitarian order, when the parts are designed to support the whole. The problem with totalitarian order is that the parts don't adequately support themselves or each other, only the whole, and the whole doesn't support the parts, only itself.

Seen with a clear understanding of what we really want in the world, chaos and totalitarian order strongly resemble each other, because they both lack what we most need. What we're striving for isn't a compromise between order and chaos; it's nowhere on that spectrum, because that spectrum doesn't take into account what really matters.

What we need is what Alexander calls "natural order" or "organic order":

We define organic order as the kind of order that is achieved when there is a perfect balance between the needs of the parts, and the needs of the whole.

In an organic environment, every place is unique, and the different places also cooperate, with no parts left over, to create a global whole - a whole which can be identified by everyone who is a part of it.

This kind of order is called natural because it's the kind of order nearly universally created by natural processes, and only rarely by artificial ones. Living processes result in parts that are fully, distinctively, amazingly themselves and yet are equally completely part of and contributing to a greater whole.

The balance between the needs of the parts and the needs of the whole allows the parts to be simultaneously highly specialized, optimized to do their jobs as well as they can be done, while simultaneously helping to create a healthy whole that couldn't exist without those parts.

Consider the relationship between the parts and the whole in the human body. A stomach and a brain are astonishingly different, each highly adapted to its job - if you had to know how to digest an apple you'd starve to death, and we all know what happens to people who try to think with their stomachs - yet each organ fully contributes to the success of the whole. You need them both to live. They're indispensably part of a whole, yet wildly different from each other.

Or consider an ecosystem. A cheetah is an amazing creature. Watch a film of a cheetah chasing down prey and you can hardly believe what you're seeing is possible. It gives every appearance of being a completely original, independent design, a master at what it does. And yet, it is simultaneously utterly dependent on its ecosystem for its survival. Without enough habitat and prey, the cheetah cannot survive. Likewise, without the cheetah, its prey overpopulate and strip bear the vegetation, causing ecological collapse and the widespread death of its prey.

In both examples, the relationship among the parts and between the parts and the whole are nothing like those relationships in a chaos or a totalitarian order.

The parts in a collection (chaotic order) are unrelated, random things. They rarely work as a whole, and never for long; they work against one another at least as often as they work together.

The parts in a totality (totalitarian order) are cogs in a great machine, all resembling each other because they're designed by the same designers. They break down readily because they do not support themselves or each other, only the whole. Place a living thing within such an order and try to use it as a part and it soon perishes because nothing in a totality fully supports the needs of the part.

The parts in a whole (organic order) look very different from one another, each highly adapted to its situation in order to be great at what it does, but if you study them long enough you begin to see the subtle common principles of their designs and to understand the ways in which they're all dependent on one another and contribute to a common whole that in turn strengthens each of them as parts.

Put another way, in organic order each part is also a whole, identifiable and supported by its own parts, by the other wholes around it, and by the whole of which it is just a part. Conversely, each whole stands for more than just itself; it also contributes to the health of its own parts, to the other wholes around it, and to the greater whole they make up together.

This quality is what makes living systems so much more scalable than artificial ones. Each scale of organic organization supports not only itself but also the greater and lesser scales. This is why as totalitarian structures get larger they get weaker - the increasing demands of the whole parasitically sap the strength of the parts - but as organic ones get larger they get stronger - the existing whole and its parts strengthen each new part added to it, and each new part in turn strengthens the other parts and the whole.

This is why the cosmos creates wholes and parts that are so vastly more complex than anything made by man, and yet those systems of wholes and parts last for millions or billions of years instead of the mere decades and centuries we manage. Chaotic order and totalitarian order may be sufficient for the trivial levels of complexity and brief time frames people usually work in, but if you need to create something vastly more complex to last for much longer, then only organic order will do.

VISTA is at that scale of complexity and longevity. It only exists because it was created using living processes that resulted in natural order, and it's precisely because VA turned away from those processes toward more totalitarian ones that it lost the ability to effectively manage or develop VISTA.

Organic order is the grail. This is what you want, and nothing less. It's a key to everything in VISTA. It's what Alexander in later works refers to as a living system, what he uses in his new definition of life in The Nature of Order. Understanding what organic order is, learning to detect its presence or absence, figuring out why it matters so much and how to create it - these are the central challenges in becoming a great VISTA manager.

Yours truly,
Rick

Postscript: Throughout this exploration, I refer to the principal author as a shorthand for the team of authors who developed these ideas and wrote this book. To set aside expediency for a moment and give credit where credit's due, here's the full bibliographical entry on this book:

The Oregon Experiment. Christopher Alexander, Murray Silverstein, Shlomo Angel, Sara Ishikawa, and Denny Abrams. New York: Oxford University Press, 1975. ISBN 0-19-501824-9. Volume 3 in a series from The Center for Environmental Structure.

Our Story So Far . . .

2009-08-20T10:39:00.000-07:00

Dear Reader,

There's an emerging order to this weblog. We began with a little introduction to VISTA before turning to the long project of investigating the VISTA software lifecycle. The first four chapters of that investigation are related in a flow of their own.

First, we started by breaking up the ground, by challenging the most common misunderstandings and filters that prevent people from being able to understand the lifecycle even when they're looking right at it. This was the chapter on the eight essential points.

Second, now, we're taking our first steps into understanding the lifecycle by using something similar that's already been well explained as a frame of reference. That's this new chapter on the principles of organic development as explained in The Oregon Experiment.

Third and fourth, after establishing that point of reference we'll drive right to the heart of the VISTA software lifecycle by examining its two essential characteristics that together set up the pattern that makes sense out of every detail of its architecture or policy: flow (fluxus quo) and life (living systems).

Thereafter, in subsequent chapters, with the main misunderstandings dealt with, a common frame of reference to compare and contrast with, and the two essential characteristics fully described, it should be easy enough to work our way through the details of how to manage VISTA effectively.

Like all plans, I'm sure this won't survive much contact with the subject matter, but let's find out.

Yours truly,
Rick

Crickets

2009-08-20T10:22:00.000-07:00

Dear Reader,

Are you there? Do you care? Am I making sense or losing your understanding or interest? Question me. Challenge me. Criticize me. I want to do a better job, but my perspective on myself is limited; I need help finding ways to make this better. I am but a man, with a man's many flaws, trying to carry this particular load for the community.

The ideas I'm trying to capture and express are a crucial part of the theoretical framework for VISTA, the part that says how to develop it. If these ideas were better understood and accepted, the evils VISTA has suffered and that veterans have suffered as a result could not have occurred without immediate public outcry. The lack of understanding of this lifecycle created the vulnerability that has been exploited for the last fifteen years. If we want to put a stop to this kind of attack on our patients, we need this book. We've needed it for a long time.

We need this book to be as good a book as we can make it, to be clear and compelling. It will be much better if we engage in a dialog now, while we can work out the ideas in electronic format. Once it goes into print, it's too late to fix the ideas or improve the explanations.

I'll make you a deal.

If you help me find the flaws in my arguments and improve the ways we explain this lifecycle, I will credit you for those improvements explicitly in the print version of the book. Public credit is as much a VISTA tradition as friendly public criticism.

Yours truly,
Rick

Principles of Organic Development

2009-08-20T09:24:00.000-07:00

Dear Reader,

Although The Oregon Experiment is the best written description so far of the VISTA software lifecycle, it doesn't describe it perfectly.

Why would it? VISTA's lifecycle unfolded according to its own path of development, in response to its own internal and external pressures, many of which emerged after this book was written. This book's such a good way to begin learning that lifecycle because it so clearly describes such a good example of an organic development-process.

Living systems, like VISTA and like physical architecture, can't be adequately managed by mechanical development-processes.

They don't need to be. There's an alternative.

Instead of mechanical development-processes, we can adopt organic development-processes, which mimic the processes living system use to produce new living systems, instead of the processes people use to produce machines. VISTA's history (including its current problems) proves we must replace VA's current mechanical VISTA-planning processes with its original (or improved) organic ones, but doing that will require understanding organic development-processes at least as well as we currently think we understand the mechanical ones.

That's where Alexander's book comes in. Alexander proposes six principles that together create an organic process for architectural planning. If you learn how these six principles guide this architectural lifecycle, which is clearly and cogently explained in The Oregon Experiment, then you're halfway to understanding VISTA's software lifecycle. Discussing this book isn't a diversion; it's a shortcut.

The similarities to the VISTA software lifecycle started by O'Neill and the original hardhats and developed over time within VA and IHS are eerie, but the differences are equally important and illuminating. We'll examine both as we explore Alexander's six principles of organic development.

There are two particular problems with this model I'll highlight throughout the exploration that follows.

First, as Alexander makes very clear, these principles aren't the ideal suite to guide organic development-processes. They're a compromise designed for overly centralized situations in which budgetary authority is and must remain centralized. This wasn't, needn't, and shouldn't be the case in VA, where local hospitals can, did, and must control part of the IT budget so they can share in the decision making. The current totalitarian degree of centralization in VA's management and funding of VISTA is a grotesque organizational illness that new VA CIO Roger Baker needs to cure for the continuing health of the veterans whose care is now his charge. The importance of class-three software in VA (a subject of its own we'll thoroughly explore in the weeks ahead) demands a return to a balance between central office and the hospitals. That healthier balance also represents a shift away from Alexander's compromise in this book back toward the purer model he envisioned but didn't document here.

Second, software and buildings share a surprising amount in common, but their differences are also important. Among other things, software's far more malleable than buildings are, so the pace of software change in a healthy VISTA organization is one or more orders of magnitude faster than the pace of construction change in a neighborhood can ever be. This creates both solutions and problems Alexander didn't have to address in The Oregon Experiment.

We'll explore his six principles of organic development with these and other differences in mind.

Yours truly,
Rick

The Oregon Experiment: Six Principles

2009-08-19T19:44:00.000-07:00

Dear Reader,

The Oregon Experiment is a quick read worth reading more slowly. Since this book is so important to understanding the VISTA software lifecycle, let's examine what it can teach us about VISTA.

Here are the book's six principles:

Specifically, we believe that the process of building and planning in a community will create an environment which meets human needs only if it follows six principles of implementation:

1. The principle of organic order.
2. The principle of participation.
3. The principle of piecemeal growth.
4. The principle of patterns.
5. The principle of diagnosis.
6. The principle of coordination.

We recommend that the University of Oregon, and any other institution or community which has a single owner, and a centralized budget, adopt these six principles to replace its conventional master planning and conventional budgetary procedures, to provide the administrative resources which will guarantee people the right to design their own places, and to set in motion the democratic processes which will ensure their flexible continuation.

For the sake of concreteness, and to give you an overview of the book, we now outline these six principles.

1. The principle of organic order.
Planning and construction will be guided by a process which allows the whole to emerge gradually from local acts.

2. The principle of participation.
All decisions about what to build, and how to build it, will be in the hands of the users.

3. The principle of piecemeal growth.
The construction undertaken in each budgetary period will be weighed overwhelmingly towards small projects.

4. The principle of patterns.
All design and construction will be guided by a collection of communally adopted planning principles called patterns.

5. The principle of diagnosis.
The well being of the whole will be protected by an annual diagnosis which explains, in detail, which spaces are alive and which ones dead, at any given moment in the history of the community.

6. The principle of coordination.
Finally, the slow emergence of organic order in the whole will be assured by a funding process which regulates the stream of individual projects put forward by users.

Next, let's examine these principles in detail, beginning with the principle of organic order.

Yours truly,
Rick

Book Recommendation 1: The Oregon Experiment

2009-08-19T13:40:00.001-07:00

Dear Reader,

To Roger Baker, the new chief information officer of the U.S. Department of Veterans Affairs, I offer this advice: if you want to be a great VISTA manager, a great VA CIO, I can recommend nothing more important than to read this book. It'll prepare you for your new job in ways no meeting or position paper ever will. It'll tell you things you need to know, things none of your subordinates can tell you. Unless you do this, you'll almost certainly repeat the mistakes of your predecessors despite your best intentions. With it, you create the possibility of becoming the second-greatest manager VISTA has ever known.

Why?

Because in the year 1975, in 190 small pages packed with illustrations, Christopher Alexander and his team came as close to describing the VISTA lifecycle as anyone has yet done in writing. It should be required reading for anyone who intends to manage a VISTA project.

The surprises here are (1) that VISTA didn't exist in 1975, except as a set of observations and principles in the possession of VISTA founder Ted O'Neill, so of course Alexander had never heard of it; and so (2) he and his team weren't writing about VISTA or even software development; they were writing about architecture and architectural planning.

They were trying to describe what seemed to most people like an unusual approach to architectural planning; it was the original approach used by humanity for millennia but abandoned in the nineteenth and twentieth centuries. This is analogous to what Ted O'Neill and his team were setting out to do in the VA: to try out a promising approach to medical-software development that defied mainstream ideas about how to develop software.

Both projects began by studying the past, studying what worked and what didn't, building up lists of tactics for how to succeed or fail, and using those lists to develop a coherent strategy. The two strategies resemble each other closely, but Alexander and his team wrote a book about their strategy, whereas we haven't yet written the book about the VISTA strategy.

Other similarities abound between the two projects. Like physical architecture, medical-software architecture is complex, easy to get wrong, and affects many people who really care about the results, and the costs of failure are paid in time, money, morale, and sometimes human lives.

Most crucially though, both kinds of efforts largely succeed or fail on the effectiveness of their management processes. You can have the best builders of buildings or code in the world, but if you manage them badly you guarantee failure - and it's easy to manage them badly. Indeed, in both disciplines bad management's not an accident but a carefully learned behavior, in which management practices that work well in other situations work badly in these two yet are adhered to forcefully even though they leave behind a track record of failure after failure.

The reason both disciplines are so vulnerable to bad management is that the two subjects share two vital characteristics: (1) flow, and (2) life. Less tersely put, (1) they both have to be managed using organic development-processes, because (2) both physical architecture and VISTA itself are living systems that only superficially resemble mechanical systems.

The full significance of that paragraph will take a few weeks to illuminate adequately, so let's get to it, step by step.

Meanwhile, order yourself a copy and read it carefully.

Yours truly,
Rick

The Essential Point

2009-08-19T07:40:00.000-07:00

Dear Reader,

Companion to the essential principle is the essential point.

What's the essential point for understanding the VISTA software lifecycle?

There are many wrong answers to that question and only one right one. The problem is that each of us prefers one or more wrong answers, for reasons we think are really good reasons. Nothing I can say can compare to the attraction of those reasons, so I'm not going to answer this question for you.

Instead I leave you with the exhortation that you have work to do on this problem, that there is no shortcut to answering it, that the answer matters, and that you'll have to work diligently and scrupulously over a long time to peel away the layers of your misunderstanding of this essential point in search of the truth.

That's not a bad thing. Work is good. Work on the right things and that work will transform you into a better person. This work, the work to discover the key to understanding the VISTA lifecycle - the real key, not the one you like - will do that too, and it'll make you a better VISTA manager.

Without this work it's all too easy, inevitable really, to violate the essential principle, as VISTA's history demonstrates over and over.

So I'll leave you with this task - it was yours already - and turn away from the eight essential points for now to a different perspective on the VISTA software lifecycle.

Yours truly,
Rick

The Importance of Project Management

2009-08-10T16:18:00.001-07:00

Dear Reader,

Lest there be misunderstanding, allow me to clarify that when I wrote

"To sacrifice medical science on the altar of project management is a form of human sacrifice"

I in no way meant to imply that project management is not needed with VISTA. On the contrary, the effectiveness of the project management seems to correlate directly with the odds of success in the last decade of projects to install VISTA outside the federal government.

High-quality VISTA-project managers seem to be among the rarest of the rare specialties in increasing demand as the expertise bottleneck gets a good grip on the community.

A great deal of what I'll be writing about in the weeks ahead assumes and depends upon a solid project-management foundation for the lifecycle to succeed.

Rather, what I meant is that within the VISTA-software lifecycle, project management must serve medical science, not attempt to dictate terms to it. Just as the approach to software development must be adjusted to be compatible with the complexity and flow of medical science, so too must project management.

To do otherwise, for example to prioritize deadlines over medical correctness, is literally to endanger our patients. There has been a great deal too much worship of timelines in VISTA management over the last fifteen years, and the health of our patients and of the software that supports them has suffered.

Replacing that kind of poor-quality, mechanical project management with experienced, fluent, and well-adapted project management is one of the major steps in launching this new VISTA renaissance.

Yours truly,
Rick

A Culture of Criticism

2009-08-09T16:48:00.000-07:00

Dear Reader,

Miss Manners, many blessings upon her, gently reminds us that it is not proper to try to parent other adults (or even children other than your own, prior to their graduation into adulthood), to correct them or criticize them, in public or otherwise.

There are two exceptions.

1) Parents can and should correct their children, preferably gently, by example, and in a way that both helps them develop into good people and also preserves their dignity.

2) Teachers can and should correct their students, much as parents correct their children but not across as broad a range of subjects, more focused upon the subjects under consideration but still including an emphasis on helping them develop into good people and preserving their dignity.

This second case applies to the VISTA community.

According to the seven-part VISTA model, our software lifecycle depends upon another lifecycle, an expertise lifecycle. The VISTA community has to be structured as a perpetual-learning organization, with each community member acting as both student and teacher to the best of their abilities. We have to cultivate our expertise and help each other develop, because we are embarked upon such a difficult mission.

In an educational context, especially one dedicated to scientific and engineering pursuits, we have to be straight with each other about our mistakes, our flaws, our bugs, our opportunities to learn and improve. This can and should be done respectfully, but it must also be done unambiguously, and if the students don't get the message with subtler forms of suggestion, more overt and direct language is called for.

The key to open-source-software development is that we work together to find and fix the problems so we can keep making our software better.

The key to an expertise lifecycle is that we do the same thing to make ourselves and our development processes better.

Even the best hardhat, the most experienced or expert hardhat, the wisest hardhat, is a perpetual student of VISTA, whose mastery will always be exceeded by the things he still has to learn.

To improve the software we must always be straight with each other about the bugs in our code.

To improve the software lifecycle, we must do likewise with our distribution of authority and our management of projects.

So, when I criticize the VA managers for their mismanagement of VISTA, it is in this spirit. I'm not setting myself up in opposition to them, or as superior to them, or on the other team from them. Mostly they're friends of mine, people I know and respect.

And in the same spirit that I critique the flaws in the programming style of my newest students, in the same say I criticize my own code when I'm team programming with my peers, I will call out the flaws in the approach of the VISTA managers. The best of them expect this of me, demand it of me.

And in doing these things, I am not doing anything special, not in the VISTA community. I am just doing my duty as a VISTA hardhat. Any of us would do the same.

In the VISTA community, we're straight with one another about the things that need to be fixed. Anyone who can't handle that must either learn to handle it or else find themselves another line of work. What we do is too important to lie to ourselves about our performance. We have to improve, always.

Our responsibility to VISTA adopters and their patients demands it of us.

Yours truly,
Rick

Humility and Courage

2009-08-08T09:59:00.000-07:00

Dear Reader,

VISTA humility requires that when Congress asks us how long something will take, our answer is "I don't know," unless it's something we've done repeatedly and consistently.

For example, we can answer how long it'll take to add a simple new report to a package we know extremely well. Or, if we've already written an interface between the McKesson Series Scheduling package and VISTA and installed it at numerous sites, we're within our rights to report how long it's taken the last five times we installed it and to suggest a similar timeframe.

If, however, we're asked how long it'll take to write an interface between a VISTA package and an external clinical system to keep the two systems in sync, we have to say "I don't know," even if we think we understand the scale of the problem. There's all the difference in the world between visualizing a solution and actually solving the problem that seems to elude most VISTA hardhats and managers alike.

Usually, about the only honest answer to questions about how long a task will take with VISTA is "Longer than either of us thinks." We're guessing about anything we haven't done repeatedly and consistently with VISTA. The moment we peg down a date on a task outside this rather confined circle of experience, we are lying. We have left humility and caution behind in favor of bold hybris, which feels intoxicating, sure, but is fraught with peril.

Why?

Because VISTA is bigger than we think it is. VISTA's ugly facts will sink your beautiful theories. VISTA sneers at your petty delusions of predicting the future. VISTA is filled with surprises.

Because these things are true of medical research, as well. Ask yourself how many times so far the answer to the question "When will we cure cancer?" has been correct. Does the comparison seem unfair? Then you are still underestimating the scale of VISTA. When I told you you were getting it wrong, you thought I was resorting to shallow rhetorical flourishes, but I'm not. From one perspective, VISTA's function is to eventually capture and represent everything we know about medicine in a consistent and logical system of data and programs that can reliably support medical practice. Is the entire field of medicine complex enough to get your attention, to make you even for a moment set aside your genetic predisposition to overconfidence and begin to quail at the scope of it? Imagine trying to sort out and systematize that field to the level of mind-numbingly stringent literalism that a computer requires.

Because medical-software engineering is not as trivial a discipline as building planes that don't crash or rockets that don't blow up on liftoff. They only have to deal with physics and weathering (and human error and politics and economics and the other universal problems). Medicine makes a lot less mathematical sense than physics, and software engineering's much easier to get wrong than materials engineering because of the relative lack of physical constraints, yet computers are vastly less tolerant of sloppiness in specification than human pilots are. Put that all together and you get a messy, difficult, complicated situation.

Because at its best software engineering is more like research and development than like engineering a bridge. The discipline of software engineering, when practiced correctly, is nearly the opposite of the discipline of physical engineering. The omnipotent malleability of software collides with the highly idiosyncratic needs of software users to create vast and shifting uncertainties. Properly practiced, software engineering is designed to be highly adaptive to the ocean of unknowns we have to deal with.

Because nine times out of ten our statement of the problem is wrong. We think we know what we're asking about, but the truth is we've grossly underestimated how much we really need or how many other features are actually involved in what we thought of as a simple, stand-alone feature.

At multiple points in the process of developing anything but the simplest changes, we're going to get checked by reality. Surprises and adjustments creep in. Sometimes it's not until the moment we begin seeing drafts of the "finished" software and realize something's very wrong here, but often the programmers return after just barely beginning the task to report they already need to change the plan because it left out something important. And usually, those two patterns occur over and over (and over and over and over . . .) throughout the development process.

Traditional project management loathes this kind of shifting of the parameters of a task. They call it "feature creep" and blame it on the users and programmers. They believe the way you keep projects on time is to stop feature creep. That's an idiotic position to take, because it leads to delivering the wrong thing on time and actually being proud of that accomplishment. It's an example of how hybris can twist people into the most ridiculous postures, into defending the most indefensible positions.

I believe, practiced properly, feature creep is the key to VISTA's success.

Giving medical practitioners what they actually need rather than the gross caricature we envision at the start of a project is what results in software that doctors and nurses can actually use to improve health care. When you're making a game or a word processor, maybe it's okay to sacrifice features to meet a deadline, but when you're making medical software do you really think it's a clever idea to pressure your programmers to cut corners or to ignore the negative feedback from doctors about early drafts of the software, just so you can meet a date that - let's face it - you had no right to give in the first place, that no matter how you came up with it was in the end a ridiculously arrogant attempt to predict the future?

To sacrifice medical science on the altar of project management is a form of human sacrifice.

There are better ways to manage medical-software projects. There are specialized forms of project management that do not begin with the pretense that R&D can be controlled, that instead harness it like an ecology, like a garden that regularly produces good things on its own schedule so long as it's properly cultivated. In a nutshell, that's precisely the VISTA software lifecycle's approach to project management.

But it all begins with admitting that VISTA development is, in fact, R&D, that it's filled with unknowns and surprises, that, in fact, "we don't know" how long significant projects will take to complete, with only the rarest of exceptions.

So here's the problem with the principle of humility.

Good VISTA-project management begins with recognizing the difference between hybris and humility, a subject that most people think they understand but that the evidence of history soundly proves otherwise. Most people, while engaged in acts of the utmost hybris, feel they're acting in a professional, responsible, and cautious manner.

In the case of VISTA managers, this is often because the political pressure they endure from Congress makes them feel small and powerless, afraid for their careers and for the future of VISTA. It is while in this mindset that the worst acts of hybris take place.

It can be very confusing, so I'll make it clear.

You should be more afraid of VISTA than you are of the President of the United States himself. If POTUS demands you tell him how long it'll take to replace the VISTA Laboratory package with a modern, off-the-shelf or custom-built proprietary solution, humility requires you to refuse to take the bait. Humility requires you to say the following:

"Mr. President, I don't know, and neither does anyone else. Most software projects fail either partly or completely, and big ones fail most of all. Replacing VISTA Laboratory's on the far end of big. Anyone who tells you such an undertaking's likely to succeed let alone when is ignorant or lying and probably both. I advise against it, Mr. President."

If you couldn't give this answer, if it seems arrogant and dangerous, it's because you haven't yet really come to terms with the degree of humility VISTA management demands of you. You're still afraid of the wrong things.

You still think angering powerful people or institutions is the worst thing that could happen to you. You are so wrong. POTUS is merely an extremely powerful man. He can only bring the human world against you if you cross him. (Besides, you never know, the President might prefer people who tell him the truth).

If to avoid disappointing him or any other man you go up against the laws of information science, it's the cosmos itself that'll grind you down. The laws of information science are as implacable as the laws of physics and far less well understood.

You should be humble. You should know your place. The health of patients cared for by the hospitals, clinics, and offices that use VISTA depend upon you to respect and fear the seriousness of your work. They need you to protect them from your hybris, no matter how the mighty incite you to it.

Managing VISTA requires humility; and, in the human world, humility requires courage.

Yours truly,
Rick

The Essential Principle

2009-08-06T10:55:00.001-07:00

Dear Reader,

The eight essential points all derive from one essential point and one essential principle.

First, the principle: humility.

Science begins with the admission "I don't know," one of the most powerful sentences in English.

Science is about the recognition that reality matters more than opinion, that when you and the world disagree, you are wrong. Kafka summed it up best:

"In any contest between you and the world, side with the world."
-- Franz Kafka, "Aphorism 52," Unpublished Works 1916-1918

It's obvious, so any sane species would hold their opinions about the world lightly, would attend carefully to every dissonance between their opinions and the truths of the world. Unfortunately, we are not quite sane, because we usually set aside caution where our own prejudices and hopes are concerned.

Science, therefore, must also be about recognizing how easy it is for people to lose track of these deep truths, how easy it is to be convinced by one's own opinions and rhetoric, to be fooled into thinking it's okay turn away from the truth of the world in favor of the seductive quality one's own ideas and prejudices have. Something in mankind finds the feeling of confidence intoxicating:

"The partisan, when he is engaged in a dispute, cares nothing about the rights of the question, but is anxious only to convince his hearers of his own assertions."
-- attributed to Socrates by Plato, Phaedo, tr. Benjamin Jowett

This is the heart of the software-lifecycle problem with VISTA. Managing VISTA's flow is a complex problem, but it's already been solved successfully. Repeatedly. We have a reliable model to follow. And yet we don't. The problem's not technical; it's human.

In Peopleware, my favorite book about how to manage IT projects, authors Tom DeMarco and Timothy Lister make the crucial observation that most people suffer from the illusion that software development is a technical field, but it's not. The technology is conspicuously present, but you can't succeed by focusing on it. It doesn't matter how great a technologist you are if you don't give people what they really need - and you don't know what they need (and they may not know either). At its core, software development is a human-relations field, in which the people who best understand the priorities, the people who best understand the technology, and the people in charge are three different groups of people. Getting them to work together well, to communicate well, and to divide up their responsibilities properly makes or breaks a software project long before the technical issues have a chance to.

VISTA illustrates their claim well, which is why the core principle is not a technical one, why the fundamental principle is one of human character. Without humility, even small VISTA projects are likely to fail.

When the question is the entire VISTA software lifecycle and how to manage it, the sober, realistic assessment is that the scale of the problem is vast and the valid judgment of each individual involved is limited. Willingness to recognize that the scale of the problem exceeds our grasp separates the humble realists from the arrogant dreamers. Humble realists have proven their ability to work miracles with VISTA, just as the arrogant dreamers have proven their ability to squander unimaginable sums of money and to endanger patient care in the pursuit of their grand designs.

Some hard scientists claim that history isn't a science, but by being managed alternately by humble realists and arrogant dreamers in succession, VA has turned its own history into a perfect laboratory that demonstrates over and over decade after decade consistent results that back up DeMarco and Lister's thesis about managing software projects.

So here we are. We have one of those situations all-too-rare in the soft sciences, in which we have a perfect match between theory and evidence. What we ought to do is obvious to anyone with the humility to do justice to the rights of the question by spending the time learning from our history and then letting that evidence guide them.

The only thing stopping us from succeeding with VISTA is our addiction to our own opinions, the rush of the eternal adolescent fantasy that with enough power we could solve all the world's problems, the illusion that the problems we must overcome are outside of ourselves.

All hail the immortal Walt Kelly for his observation "We have met the enemy and he is us." Humility demands that we accept the truth of this. It's the only real explanation for the mess the VISTA community finds itself in today.

Fortunately, it's also the key to getting out of this mess. If we embrace the principle of humility, if we acknowledge the limitations of our expertise, then we can roll up our sleeves and overhaul our allocation of VISTA authority to break up its unhealthy and insane centralization, then we can distribute each kind of VISTA authority into the hands of only those people who hold that kind of expertise.

Humility does not require us to give up, or to assume a posture of helplessness. This is not a jump off a cliff into the unknown. This is a return to the most effective model of management VISTA has ever known, in which authority is decentralized but concentrated according to expertise, reaping all the supposed benefits of centralized VISTA control with none of the all-too-real flaws.

This is why the eight essential points all derive from the principle of humility. If we can muster the courage to admit that no one of us nor any small group of us can possibly know enough to manage something of VISTA's scale of complexity, then all the elements of the VISTA software lifecycle follow as inevitable solutions to that problem.

Yours truly,
Rick

Eight Essential Misunderstandings

2009-08-04T22:08:00.000-07:00

Dear Reader,

The eight essential points I have summarized so far aren't the sum total of the things you need to understand about the VISTA lifecycle. They aren't even a comprehensive overview. They don't even represent the majority of the main issues.

They're just the clearest refutations of the eight most common misunderstandings about managing the VISTA software. You can't really understand the VISTA software lifecycle unless you can recognize when you aren't doing it.

So here they are. See how many of these destructive VISTA practices you recognize.

-1. VISTA should be managed with an industry-standard software lifecycle.
-2. Managing VISTA requires a central code repository.
-3. Managing VISTA requires strong, centralized leadership.
-4. Expert project managers must control VISTA's software lifecycle.
-5. User requests should be submitted to a sophisticated review process.
-6. Programmers should work on whatever their managers tell them to do.
-7. Politically important projects should get top priority.
-8. VA is the VISTA producer, everyone else VISTA consumers.

Yours truly,
Rick

Point 8: Declare Interdependence & Confederate

2009-08-03T13:06:00.000-07:00

Dear Reader,

Once upon a time, Ted O'Neill and Marty Johnson set into a motion the VISTA software lifecycle, which resulted in continuously improving medical software so popular with the users that the VA and congress reluctantly agreed to set aside their multi-million dollar failed boondoggles and do the right thing. For seventeen years the VISTA lifecycle made VA the main hub of VISTA development worldwide. With VA providing such a reliable heartbeat for that lifecycle, everyone else could afford to remain comparatively disorganized so long as they stayed in a symbiotic relationship with VA and its lifecycle.

The future before us is very different. With VISTA spreading all over the world at an increasing pace and VA's mandate restricted to healthcare for veterans, VA will shift from the center of the worldwide VISTA lifecycle to become a peer. That will require a radically different form of relationship among the various VISTA-interested organizations, one in which the heart of the lifecycle does not exist within a single organization but across multiple, sometimes competing organizations. This form of relationship has a formal name. It is called a confederation. The future of the VISTA community is a worldwide confederation.

The present, caught between that past and this future, demands a time of radical but wise change. Now is the time for the transformation of our community. Now is when we must breach the barriers that separated us into autonomous feudal kingdoms, each with its own dialect of VISTA. Now we must declare our interdependence and forge the formal alliances that will pave the way for confederation, supporting our need to compete and innovate while still collaborating on the shared lifecycle and software upon which the health of our patients depends.

The world has begun to marvel at VISTA, to realize the amazing power it has to help doctors and nurses save lives. But we know they haven't seen anything yet. We know the real power is in the software lifecycle that created VISTA, a lifecycle we are about to unleash again to work its miracles for us. We know the world is in for a wonderful surprise.

Yours truly,
Rick

Point 7: Restart the Lifecycle with Fileman and Forum, part two

2009-07-29T08:58:00.000-07:00

Dear Reader,

. . . continued from part one, yesterday.

Rebooting the VISTA lifecycle will also require the right license for the software. We can't use a license for the core infrastructure packages that discourages the widespread adoption of the common shared VISTA core, by adopters and developers alike. If that core isn't kept in common, particularly the infrastructure packages like File Manager and Kernel, then VISTA will continue to balkanize into mutually unintelligible dialects, drifting apart as the VA and DOD dialects have done.

Although there may be VISTA packages for which the GNU Public License (GPL) is a suitable license, it's certainly not suitable for the core infrastructure packages because of the extreme degree of integration these packages have with all other VISTA packages, an integration so extreme it pushes past normal definitions of such terms as "derived works" and "interfaces." This unavoidable mismatch between the GPL's terminology and VISTA's unique internal structure makes eventual court battles over licensing violations highly likely, and offers no guarantee that such lawsuits would be decided on the basis of a reality most people don't comprehend and the rest can't explain clearly. That is, although the GPL isn't inherently incompatible with File Manager, for example, its terminology misrepresents Fileman's relationship to the rest of VISTA so badly as to make it an unreliable safeguard of our intentions.

Whether the license for the VISTA infrastructure packages needs to be the Lesser GPL, the Eclipse Public License, or some other open-source license is a question that needs to be sorted out in short order so we can get on with the work such licenses are intended to safeguard.

Most people should never ever work on the File Manager or Forum software because of how complex they are and because of the potential of problems in these areas to affect every other VISTA package, but they must be our top priorities. With the right experts leading these efforts, they'll be the right projects to restart the lifecycle.

Yours truly,
Rick

Point 7: Restart the Lifecycle with Fileman and Forum, part one

2009-07-24T08:54:00.001-07:00

Dear Reader,

It's taken roughly 1,000 programmers driven by tens of thousands of users over thirty-two years to get VISTA to its current level of sophistication. To achieve a VISTA-lifecycle renaissance will eventually require something similar.

But VISTA didn't start on such a scale. Back when Ted O'Neill and Marty Johnson first launched what they called the MUMPS Systems (VISTA's first name), they only had about twenty-four programmers responding to a small population of users. That was plenty to create a system easily recognizable as the ancestor of today's VISTA, and it'd be plenty to get things moving properly again.

To prime the pump, we should begin even smaller, with two small teams focused on two areas.

First, we should build on Medsphere's excellent File Manager work to create File Manager version 23. Fileman is the easy choice because it's the core architecture for all of VISTA and therefore the most important point at which to begin reinvigorating VISTA, since every VISTA package benefits from Fileman's improvements. That one package'll be enough for us to restart, test, and refine the VISTA software lifecycle.

Second, to refine that lifecycle we'll need to be able to fix or improve its software too - KIDS, NOIS, Patch Module, and the other packages that run on or communicate with Forum - as we proceed with Fileman, so that should be the other subject of our work, the focus of the second VISTA-development team.

This'll require funding for the core developers for each of those packages plus the small constellation of students we need to surround each one with. It'll also require funding for a Forum system manager and his students, a verifier and her students, and a database administrator and his students. The right fifteen to eighteen people could make this fly.

After the prototype lifecycle is up and running, we should plan to expand it to include the Kernel, Victory Programming Environment, and Laboratory packages (for reasons we'll explore in future postings), with a team of four to six people, mostly promising students working under the top gurus for each package.

To be concluded in part two, tomorrow. . . .

Yours truly,
Rick

Point 6: VISTA's Software Stream Has Many Tributaries, Part 2

2009-07-23T11:11:00.000-07:00

Dear Reader,

. . . Continued from part one yesterday.

Although it hasn't happened much for the last fifteen years, a vital part of this software stream is that every year or two each package should release a fresh version of their entire package, an upgrade that goes through a more intense re-engineering, documentation, testing, and verification cycle than patches get. This helps keep each package's architecture fresh and provides a deep housecleaning period to flush out the subtler or more intractable bugs. So, the "patch stream" is actually a software stream that includes both patches and new versions.

So what about complete snapshots of VISTA? Most software in the world is managed by releasing entire new snapshots. What about VISTA?

Well, this is part of where the VISTA lifecycle turns everyone's expectations on their head, part of why our software lifecycle doesn't begin with a single code repository. Nobody upgrades VISTA with a complete snapshot. VISTA's code and data are and must be far too intricately intertwined to simply swap out all the code like most software does. Instead, we upgrade with incremental changes, with patches and new versions of individual packages. At best, VISTA snapshots are useful for starting a brand-new VISTA system from scratch.

Even if VISTA weren't so vast as to be unmanageable as a single codebase, this is the other reason we do not begin the software stream with a single code repository - because most VISTA adopters have little use for new snapshots. Instead of being the source of the stream, the VISTA platinum account (the clean and shiny VISTA codebase from which snapshots are created) is just another recipient of the software stream at the end of one of its delta channels, like any other VISTA system. That is, the platinum code repository is a recipient, not the source, of the software stream. It has to be.

VISTA can only be managed piecemeal, with all its separate threads of user feedback and incremental changes being woven through Forum to create the fabric of VISTA.

Yours truly,
Rick

Point 6: VISTA's Software Stream Has Many Tributaries, part one

2009-07-22T08:08:00.000-07:00

Dear Reader,

In the classic VISTA lifecycle, each VISTA development team relies on user feedback in the National Online Information Sharing package (NOIS) on Forum to figure out its top priorities, but the changes are not made on Forum nor on any central code repository, as discussed in point two. Instead, each package-development team develops its changes in its own package-specific code repository. Developers do not need permission to make changes to their software; they are the tyrannical owners of that software, and they continue to be just so long as they keep their users happy.

Once the developers have solved a problem, they bundle it up using the Kernel package's Kernel Installation and Distribution System (KIDS) and e-mail it to Forum. Using another special Forum package called the Patch Module, they convert the KIDS distribution into a patch and distribute it for testing, verification, and eventually release. The Patch Module maintains a list of subscribers for each VISTA package, so when a patch is released it is automatically e-mailed to all of its subscribers. The power of this e-mail-based push mechanism is something we do not have time to get into in this posting, except to say this is what makes the pending auto-patch system work.

Conceptually, this means the software stream does not flow to a single mouth, a single repository where people have to go to ﬁnd upgrades. Rather, after Forum the software stream splits into a delta that delivers a stream of software to each subscriber.

This explanation should make clear that the patch stream, the nonstop sequence of incremental improvements to VISTA, also does not begin with a single source, but with many sources, maybe between fifty and a hundred. Forum's role on this outbound half of the lifecycle is strictly that of a traffic cop who sequences the traffic, not that of traditional software manager who controls what gets done and whether it can be released. Forum's role here is to act as the point where the tributaries come together to form a single stream.

Although from the VISTA adopters' perspective Forum produces the steady stream of small advances they can trust to continuously upgrade their systems, from the developers' perspective it is still very easy to separate out, think about, and manage just the thread of development that represents their chosen package. This is how the unmanageable scale of VISTA development is broken down into incremental steps organized into manageable packages and corresponding patch streams.

Concluded in part two tomorrow. . . .

Yours truly,
Rick

Point 5: Users and Programmers Need a Shared Forum, part two

2009-07-07T07:28:00.000-07:00

Dear Reader,

. . . resuming from part one, yesterday . . .

How to configure Forum and how it works to organize user requests and encourage dialogue are topics we'll spend a great deal of time on in this blog, eventually, but for now I just want to make three observations.

First, someone needs to host this system and supply a VISTA-savvy system manager to run it. This is a responsibility, and it supplies a service that everyone needs, but there is no strategic advantage to being the one who runs it. You can't charge for it without screwing up the VISTA lifecycle, and you can't tamper with the ﬂow of dialogue between users and programmers. It's a responsibility that carries with it shared benefit but no advantage over the other VISTA vendors and organizations. At the moment, the network is testing out the Forum software on its Paideia educational server, and our community could start out by using that until we're ready for a more robust system.

Second, because VISTA is medical software, sometimes problem reports must include patient information to properly diagnose. The only way this is ethical and legal is if all of Forum's users (programmers and users alike) have signed Health Insurance Portability and Accountability Act (HIPAA) agreements to respect the privacy of all patient information they see there. That's only possible if Forum is not open to the world, only to the finite community of actual VISTA programmers and users.

Third, Forum is not an optional or replaceable part of the VISTA lifecycle, though it's the first part that open-source enthusiasts get excited about replacing, usually the moment they hear the words "problem reporting." Everyone wants to use either their home-brewed pet software or else the latest fad that's sweeping the open-source community. Such petty arguments over toolsets are at least half the reason why, eight years after I first proposed setting up a shared Forum system outside VA we still don't have one up and running.

So this time, let's sidestep this problem by starting out with the only hub ever proven to work with the VISTA lifecycle. Later, after the lifecycle is underway and we are all productively developing VISTA we can tinker with our toolset, but for now, I refer you back to the first point I made (five posts ago). Let's try to suppress our urge to tamper with the VISTA lifecycle before we truly understand it.

The shared Forum accomplishes half of the VISTA lifecycle: it gets the development priorities properly set in response to user needs. After that, the second half of the lifecycle is "easy."

Yours truly,
Rick

Point 5: Users and Programmers Need a Shared Forum, part one

2009-07-06T11:49:00.000-07:00

Dear Reader,

A user-driven lifecycle begins with teaching your users how badly we need their ongoing input about what works for them and what doesn't in VISTA. This is much harder for them today than it was in 1994 because mass-market software companies have taught them that no one gives a damn what works for them as long as they keep forking over the cash, that the programmers only work for them in some abstract, marketing sense. In our experience, it takes some work on your part to overcome this learned passivity, but the users who break through tend to become persistent chatterboxes, which is what we all need.

Next, we assume the majority of your users' VISTA requests are reported and resolved by the hospital's own Information Resources Management or Health Information Systems personnel, or by your immediate support organization's expert troubleshooters. The vast majority of problem reports are resolved with training, improved documentation, or through making minor local configuration changes to VISTA, and still others can and should be resolved with forward-compatible local extensions to VISTA (class-three code). That is, a user-driven software lifecycle does not require you to air all or even most of your dirty laundry; each support organization handles the majority of its own problems. All of this can be handled through whatever local problem-reporting system you like.

But when it comes to problems that require shared changes to VISTA, problems requiring the attention of the VISTA package-development teams, VISTA problem-reporting cannot require the use of eighteen different systems for eighteen different organizations. We need to use a single, specialized problem-reporting system that's evolved over the decades to support our VISTA development teams, the one they're most comfortable and efficient with, the only one specifically designed to support the VISTA software lifecycle.

At the hub of the VISTA lifecycle is a single system called Forum. Forum is where users and VISTA teams carry on their continuous dialogue about how VISTA is working and not working for each user, where users formally make requests for changes to VISTA.

Forum is a VISTA system. It runs VISTA. Any VISTA system could be configured as a forum system, but we only need or want one to ensure we get all the user problem requests into one place where they can drive our development priorities. Conﬁguring a VISTA system as the forum system mainly involves ignoring all the medical, financial, and administrative packages in VISTA and properly setting up its communication packages. For example, one of the special VISTA packages Forum uses that most VISTA sites ignore is National Online Information Sharing (or NOIS), the main problem-tracking package; most VISTA sites don't use this package, but on Forum it's one of the main packages used.

To be concluded in part two, tomorrow . . .

Yours truly,
Rick

Point 4: Users Must Directly Control VISTA's Lifecycle

2009-07-03T10:15:00.000-07:00

Dear Reader,

VISTA is too important to healthcare to leave its fate in the hands of managers, programmers, politicians, or entrepreneurs. Really, only VISTA's actual users - nurses, doctors, pharmacists, lab techs, radiologists, and other medical and support personnel - know precisely how they use VISTA second-by-second every day, so only they can really know how it falls short in supporting their work. Of all the people involved with VISTA they are also the only ones directly contributing to patient care, which after all is the point of this entire enterprise.

Therefore, in the VISTA lifecycle model, although anyone can request VISTA changes, user requests trump all other priorities. Directly. Not as interpreted for them by managers, experts, committees, or other bureaucratic forms of user disempowerment. User requests are collected and used directly as the marching orders for the VISTA development teams.

Users are the fourth and most important element of the VISTA model of authority. It is the users who decide what each team works on, and not by sorting through or voting on priorities but simply by reporting the problems they are having and requesting bug ﬁxes or enhancements. As the reports accumulate, the urgent problems identify themselves and do not require committees or expert panels to identify.

Many people ﬁnd this element of the VISTA lifecycle idealistic, but since all of their proposed alternatives have failed over and over to the tune of billions of dollars wasted, and since this model not only worked for seventeen years but produced the greatest productivity and responsiveness the VISTA world has ever seen, I ﬁnd the idea of doing anything other than user-driven VISTA development ridiculously idealistic. A properly organized VISTA lifecycle very nearly runs itself, using specialized tools and techniques of information management.

Yours truly,
Rick

Point 3: VISTA Requires Many Authorities, Not One

2009-07-02T11:48:00.000-07:00

Dear Reader,

An unimaginable amount of expertise went into creating VISTA, and that same degree of expertise is required to manage it. Managing the VISTA software lifecycle requires more expertise than you have, more than I have, more than anyone has, but it also requires more speed and accuracy than any group is capable of. Any individual in charge of VISTA would be ignorant of 99% of the subjects needed to manage all of VISTA, and in any group large enough to include all the experts needed, 99% of them would just be in the way for 99% of the decisions. There is no form of centralized authority capable of managing VISTA effectively, no matter how you divide up the code into repositories.

That's why VISTA's second name, before "VISTA," was the Decentralized Hospital Computer Program, because no central authority can manage it, no matter how smart or powerful or well funded they are or how good their intentions. VISTA authority must be decentralized.

However, history has demonstrated that VISTA authority also has to be efficient and responsive enough to keep up with the changing needs of medicine, has to avoid the chaos of a free-for-all, and has to avoid the endless debates over trivia to which democratic communities are all too prone. Each VISTA authority must have near-tyrannical powers over their chosen part of VISTA to ensure maximum efficiency. That is, VISTA authority must not only be decentralized, it must also be concentrated.

VISTA also requires a third element in its governance. Each VISTA package is so complex it can only be effectively managed by dedicated expert programmers who can focus on mastering their chosen package over very, very long periods of time, like a decade or more. Most VISTA packages are too complex for any single expert programmer to manage, certainly too complex for dilettantes to manage effectively, so teams are required. And so, VISTA authority must also be expert.

The resulting form of governance, to have authority decentralized and concentrated into the hands of many near-tyrannical, permanent expert teams, is so weird there isn't even a name for it - for now let's call it the VISTA model of authority - but history has proven that whatever you call it, it is capable of managing VISTA better than any other authority structure.

So here's a vital part of the VISTA lifecycle recipe: decentralize authority, divide it up by subject, and allocate it to teams of expert programmers. Each team manages one VISTA package's code repository, with the senior experts in charge of each team.

This part of the recipe is necessary but not sufficient. After all, who is in charge of the senior experts? Who decides what the priorities are? That's the subject of my next post.

Yours truly,
Rick

Point 2: VISTA Requires Many Code Repositories, Not One

2009-06-26T23:27:00.000-07:00

Dear Reader,

VISTA's bigger than you think it is - vastly bigger - by scales of magnitude. None of the numbers you can put next to it (files, programs, lines of code, function points) comes remotely close to its actual complexity and sophistication. The interaction of its intricate integration with its unparalleled extensibility creates intricate effects that VISTA depends on but that we don't begin to know how to measure. Fortunately we don't have to.

We just have to understand that it is very, very big, too big to be effectively managed as a whole, unlike most software in the world. Bluntly put, as a whole VISTA is unmanageable. If you try to manage VISTA from a single code repository, your VISTA codebase will stagnate and your productivity will fall over time. You'll know you've begun to grasp the scale of VISTA when the idea of a single, central code repository for managing VISTA literally makes you laugh. Until then, you're not even close.

Fortunately, you don't need to begin with a single code repository to manage a shared VISTA code base. The VISTA lifecycle sure doesn't.

Instead, we follow the traditional divide-and-conquer strategy that makes computer science possible. We break up VISTA into packages and manage each package with its own independent code repository. In our experience, this reduces the scale of the problem enough that a highly expert, dedicated team can almost - almost - keep up with the problem of managing just that one package.

So, throw away the idea of beginning your VISTA lifecycle management with a single, complete gold account, and replace it with the idea of many gold accounts, one per package.

Yours truly,
Rick

Point 1: VISTA Requires the VISTA Software Lifecycle

2009-06-25T12:28:00.000-07:00

Dear Reader,

Over the thirty-two years of VISTA development, many, many different software lifecycles have been tried with it, and all but one of them have failed, sometimes subtly, sometimes spectacularly.

Interestingly, for the last fifteen years no one has consistently tried to follow that one proven model, and during that time every VISTA adopter has struggled with VISTA. Those who have deviated the least from the model, like Indian Health Service, have enjoyed the most success, and those who have deviated the most, like the Department of Defense (DOD), have suffered the most. Veterans Affairs (VA) makes the best test case to prove this point, since they have been at their most productive with VISTA when they followed the model, and at their least when they didn't.

From studying VISTA’s rich and varied thirty-two-year history, I draw this radical proposition: we should take the plunge. We should end the fifteen-year drought by completely following VISTA's own software lifecycle model, the one that worked.

Getting to know the VISTA software-lifecycle model will take time, because it is sophisticated, complex, undocumented, and no example of it exists today, but I am confident that the more you get to know it, the more you will come to agree with me that the weird qualities of this model exactly support the weird qualities of VISTA in a way no borrowed or adapted model ever can.

Of these first eight points, this is the simplest, the most important, and the least likely for anyone to believe. I wish that weren't true, because this is the crucial missed point at which most VISTA adopters went off the tracks since 1994. If you can resist the urge to "improve" a model you do not yet understand, if you can compel yourself to study it patiently as though it were complex enough to deserve your attention, then you can buck the odds and reap the rewards that come with it.

Yours truly,
Rick

Eight Essential Points

2009-06-24T12:44:00.000-07:00

Dear Reader,

Let's begin with eight important points about the VISTA lifecycle, which I presented remotely at WorldVistA's nineteenth VISTA community meeting at the National Library of Medicine in Bethesday, Maryland. I lacked the time during that presentation to fully introduce these points, so let's do it here over the next eight days.

These points are:

1. VISTA requires the VISTA software lifecycle.
2. VISTA requires many code repositories, not one.
3. Managing VISTA requires many authorities, not one.
4. Users must directly control VISTA's software lifecycle.
5. Users and programmers need a shared forum.
6. VISTA's software stream requires many tributaries.
7. We should restart the lifecycle with just File Manager and Forum.
8. We need to declare interdependence and form a confederation.

Yours truly,
Rick

VISTA Lifecycle: Let Us Begin

2009-06-23T23:23:00.000-07:00

Dear Reader,

"VISTA is a process, not a product," say VISTA hardhats, but what do they mean? Let's find out.

The process is called the VISTA lifecycle, and it only superficially resembles any other software lifecycle. To follow it, you have to change everything about your software support and development - how you fund it, how you design it, who's in charge, how training takes place, and more. If you're willing to make these profound changes you can accomplish amazing things with VISTA.

Although the VISTA community depends on this lifecycle, no one has documented much of it. Let's do it.

It's a complex subject. My best guess is that it'll take the rest of 2009 just to finish a first draft. Rather than wait while I write and publish a refined explanation, let's sort it out in the open, together, here, in this blog.

One caveat: everything in VISTA's lifecycle is connected. Anything that seems to make sense by itself is really part of a far more complex system, and the meanings of things deepen and change when you come to understand how they relate to everything else.

This is a deep subject that needs and deserves patience and persistence, that rewards them with the ability to change the world for the better.

Yours truly,
Rick

Small-capital Confusion

2009-06-03T09:38:00.001-07:00

Dear Reader,

When I wrote "Capital Confusion," I was only able to demonstrate the use of small caps back to the Domesday book of 1086 AD, leading me to believe along with Robert Bringhurst that they were added to our standard writing system after lowercase was invented.

I have since learned that smallcaps go back much further than a thousand years. Indeed, they predate lowercase. The creation of lowercase by Dark Age scribes took centuries, with numerous alphabetic inventions along the way. Although most of these intermediate alphabets fell by the wayside once Alcuin and other Carolingian scholars refined the lowercase alphabet to something like its current form, two of them survived.

Uncial, also called insular, a unicameral alphabet, was developed largely by celtic Christian scholars and remains to this day associated strongly with Ireland, Scotland, and other celtic countries. If you look at an example of it understanding its status as an intermediate development between upper and lower case, you can see how it contains elements of both. It was not folded into our culture's standard suite of alphabets, but remains to this day a specialty alphabet used to create an emotional or cultural effect in the text.

Long before uncial, however, small caps were developed as one of the first of these intermediate alphabets. If you search diligently, you can find examples of ancient Roman inscriptions set in caps plus small caps. Unlike uncial and the other intermediate alphabets, small caps remained a standard part of the scribes' toolset, and later became a standard typographers' tool as well.

The small-caps alphabet's apparent obscurity or optional character today is a conceptual illusion created during the industrial, reductionist craze of the nineteenth and twentieth centuries, when small caps and lower case figures temporarily fell out of fashion. (In case you think the industrial attempt to purge these two elements of our writing system was reasonable, consider that they also tried to purge lowercase as well, to reduce writing back to all caps. DOES THIS IRRITATE YOU? HOW ABOUT NOW? HOW MANY PAGES OF THIS SHOUTING DO YOU THINK YOU CAN READ WITHOUT GETTING A HEADACHE?)

The absence of these two important typographic inventions was reinforced starting in the 1870s when Christopher Sholes's QWERTY keyboard became the basis for typewriter key layouts, which in turn became the core of the design for computer keyboards. This crude design omits numerous typographical characters - including text figures and small caps - leading the overwhelming majority of people to believe by default that Mr. Sholes's invention somehow defines the official character set of the English language. It does not. Many essential elements of our writing system - including entire alphabets - are missing from modern keyboards.

Small caps and text figures are essential to protecting the readability of the modern Roman alphabet, especially when we have come to rely so heavily on acronyms and numbers in our writing. The absence of small caps and lowercase figures appears normal to us only because we have become habituated to it. Type designers are decisively ending this industrial-era experiment in reductionism by including small caps and lowercase figures in most serious, professional typefaces produced since the 1980s.

Hence, if my recommendation in "Capital Confusion" to use small caps (when available) to set acronyms like VISTA appears eccentric or needlessly fastidious, I encourage you to broaden your horizons, to learn a bit more about the history of your own writing system, to remove the blinders you have taken for granted, blinders imposed on you without your knowledge or consent by people who did not have your best interests at heart.

For an excellent eighty-three-page introduction to typography, a quick and illuminating read, try Finer Points in the Spacing and Arrangement of Type by Geoffrey Dowding (ISBN 0-88179-119-9).

A better known and highly respected, more in-depth guide to typography is Robert Bringhurst's The Elements of Typographic Style (ISBN 0-88179-206-3).

Yours truly,
Rick

Postscript: Learning is good. Learn more.

Postpostscript: Questioning authority is good. Start with the authority your own assumptions, biases, and habits hold over your mind. Wake up.

Postpostpostscript: Subtlety, nuance, and mastering the details are good. Sweat the little things. Pay attention.

Postpostpostpostscript: The deeper point of this and the previous post is that we know much less about the world and ourselves than we think we do, that not only are we liable to make mistakes about complex subjects like VISTA, we cannot even get right such simple subjects as how to capitalize it properly or even the nature of our alphabet. An open and inquisitive mind eager to explore the unknown and to discover its own errors in fact and judgment is far better preparation for dealing with VISTA than any amount of confidence, experience, money, or political power.

Indeed, as we will explore in this blog, the greater your success with other ventures, the greater your odds of failing with VISTA, exactly because your success leads you to overconfidently trust in tried and true ways of looking at the world that fail badly when applied to VISTA.

Capital Confusion

2007-05-07T15:16:00.001-07:00

Dear Reader,

The abbreviated name of the Veterans Health Information Systems and Technology Architecture, VISTA (named in 1996), is not the same as the unabbreviated word vista, meaning a view or prospect, an avenue or passageway opening onto such a view, or a mental view. Nor is it the same as the second word in the name Windows Vista (announced in 2005), which is a proper-noun form of the unabbreviated word, as is John Wall's business software and services company, Vista (formed in 1999). In English when we convert an unabbreviated noun into a proper noun, we capitalize just the first letter, as Microsoft and Wall have done here.

Our VISTA is like the abbreviated names for Volunteers in Service to America (formed in 1964), Ventura Intercity Service Transit Authority (formed in 1994), Visible & Infrared Survey Telescope for Astronomy (announced in 2000 and due to be completed this summer), and the emerging market Vietnam, Indonesia, South Africa, Turkey, Argentina. All of these names fall into that special class of abbreviations known as acronyms, words formed entirely of the initial letters of other words and hence capitalized entirely in uppercase, or smallcaps, or (as I will propose) in special cases in smallcaps with the first letter in uppercase, but never with a mix of upper-and-lower case.

That is, the name of our software is not and never was properly capitalized in text matter as VistA, despite the widespread practice even by the Department of Veterans Affairs (VA), WorldVistA, the VistA Software Alliance, and others.

Written English words appear in two different contexts, text settings and display settings, for which typesetters understand there to be two different sets of rules. Text settings adhere to the rules of English grammar, including capitalization. Display settings, such as advertising, title pages, logos, and so on, fall somewhere between text and art; the typesetter understands that the rules may be bent or stretched to adjust the emotional or aesthetic impact of the words. Although a great deal of thought goes into the design of display settings, so does a great deal of fad and fashion, which pass through the practice of display typesetting in waves so pronounced that most such work can be precisely dated later on. That is, what seems fresh today tends to seem fresh to everyone all at once; today's fresh is tomorrow's cliche. Current crazes include all-lowercase names and titles, rounded, wide, thin, sans-serif typefaces, and happy, shiny, friendly text treatments like reflections, glows, and shadows (spend some time searching the web for famous logos redone in Web 2.0 format, and you'll see what I mean; I'm especially fond of the Quaker Oats spoof).

Good or bad, all of this play with the rules is permitted in display settings such as logos, but not in text settings, not even with names in text. The logo of the television show Planet Earth may be in lowercase Helvetica Extended Thin, but in text matter the name is capitalized like any other proper noun. The film with the name Seven had a logo in which the v was replaced with the numeral 7 like this: SE7EN; this distinction between names and logos so confounds most of us that to this day otherwise educated fans of the film will pounce on anyone who spells the name correctly and insist they misspell it as the logo does. When this kind of confusion occurs, when a writer loses track of the difference between a name and a logo and begins using logo treatment in text, the result is called a logogram, a logo masquerading as a word. In The Elements of Typographic Style, master typographer Robert Bringhurst sums up the problem with logograms like VistA:

Logograms present a more difficult question. An increasing number of persons and institutions, from e. e. cummings to WordPerfect, now come to the typographer in search of special treatment. In earlier days it was kings and deities whose agents demanded that their names be written in a larger size or set in a specially ornate typeface; now it is business firms and mass-market products demanding an extra helping of capitals, or a proprietary face, and poets pleading, by contrast, to be left entirely in the vernacular lower case. But type is visible speech, in which gods and men, saints and sinners, poets and business executives are treated fundamentally alike. Typographers, in keeping with the virtue of their trade, honor the stewardship of texts and implicitly oppose private ownership of words.

Logotypes and logograms push typography in the direction of hieroglyphics, which tend to be looked at rather than read. They also push it toward the realm of candy and drugs, which tend to provoke dependent responses, and away from the realm of food, which tends to promote autonomous being. Good typography is like bread: ready to be admired, appraised and dissected before it is consumed.

The VA's first VISTA logogram in which the "IST" are sloped smallcaps (which cannot be reproduced elegantly on the web without a picture) is the fault of the VA, which introduced it into its documentation shortly after the name was announced; it would have been fine (if not especially effective) as VISTA's logo, but it was hardly ever used as such, mainly as a logogram in text settings. It also was not presented as the abbreviated name, which had already been established to be VISTA, but instead was inserted without explanation in most text settings in place of the name. Although individuals, organizations, and their commercial products are legally allowed a wide latitude in how their names are capitalized, in practice even if you include all the name syntax variants of all cultures that use the Latin alphabets, there are still only a narrow range of variations in capitalization; if you capitalize very much outside that narrow range, the results are unnatural and distracting. This first VISTA logogram is well outside the natural range of capitalization for names, as are e.e. cummings and WordPerfect (the proper capitalization for each stage in the evolution of such a compound word would be from Word Perfect to Word-Perfect to Wordperfect; cf. Coca-Cola). Further, if you look closely you will notice that the middle three letters are not just smallcaps but sloped, i.e., pseudo-italic; requiring italic or sloped treatment of letters is perfectly permissable in logos but well beyond the pale for names.

The web version of the VISTA logogram (which the VA currently uses on its VISTA Monograph Homepage and elsewhere) unable to reliably produce smallcaps in a webpage, keeps the sloped capitals for "IST" and bolds the "V" and the "A." Go look at the text on that webpage now to see how the resulting logogram, especially its first and last letters, dominate the surrounding text, utterly distorting the flow of the text.

The logogram "VistA" is largely my fault. When I was first exposed to VA's VISTA logogram, I knew little about typography and had been steeped enough in commercial culture to accept such grammatical violations, so when I referred to VISTA in e-mail settings lacking the capacity for smallcaps or italics I coined "VistA" in an attempt to capitalize VISTA "correctly." In the roughly ten years since its introduction, I have written and taught a great deal about VISTA, and I'm afraid I've been something of a Johnny Rotten-Appleseed where the proliferation of this third VISTA logogram is concerned. I could trace out the sequence by which first many hardhats within VA, then WorldVistA, then VA itself, and then the VistA Software Alliance adopted my incorrect approximation of VA's logogram, which itself was poor grammar to begin with, but to make a long story short, I hereby formally apologize for leading us all further into grammatical error.

As penance, I pledge to work to educate people and organizations as to the correct capitalization of the name of our software and our new organization. The following guidelines apply to text settings, since in display settings you are restricted only by the bounds of creativity and (if we are lucky) good taste. The VISTA Expertise Network does not insist others follow these guidelines, only that we do.

First, it will probably never be proper to use roman lowercase anywhere in the name VISTA. Although laser and radar traveled the road from allcaps acronyms to lowercase unabbreviated words, they were neologisms and so did not have to displace existing English words to make their metamorphosis from acronymic abbreviations to unabbreviated words. VISTA by contrast deliberately echoes the English word vista, and so cannot ever lose its capitals without creating confusion. This rules out our software ever being referred to as vista or Vista, and the rules of good grammar rule out any logogrammatical mixtures of upper and lowercase such as VistA.

Second, it is always acceptable to fall back on the default capitalization for acronyms, all uppercase (aka "allcaps"), such as VISTA. In inadequate text settings that offer only a bicameral alphabet (upper and lower cases), we are forced into a choice between overly emphasizing acronyms with uppercase and confusing them with unabbreviated nouns with lowercase; the noise of distortion is preferable to outright confusion, so allcaps is the preferred capitalization of the name VISTA in bicameral settings such as e-mail and websites.

Third, to blend acronyms like VISTA with surrounding lowercase text without introducing confusion, smallcaps are the preferred capitalization. Although typewriters, keyboards, and English teachers would lead us to believe that English is a bicameral alphabet that marries an uppercase and lowercase to create a whole alphabet, English is actually tricameral, including a third case: small capitals. That case has been with us for at least a thousand years, almost as long as uppercase and lowercase have been married (only about two hundred years longer); for example, a close examination of the Domesday book of 1086 reveals the use of smallcaps in place names throughout the text. English has been tricameral (upper, lower, and smallcaps) for five- to six-hundred years longer than we've had italics (introduced in the late fifteenth-century Renaissance) and about nine-hundred years longer than we've had boldface (introduced during nineteenth-century industrialization). In ordinary usage we tend to ignore the smallcaps case, mostly out of ignorance but partly out of sloppiness; however, when setting type carefully, the third case becomes useful for subheads and other special kinds of emphasis and essential for properly setting acronyms within lowercase text. True smallcaps, carefully designed to match weight and color with the other two cases, are vastly preferable to the spindly pseudo-smallcaps word processors tend to generate when you "apply the smallcaps attribute" to lowercase letters, but even pseudo-smallcaps are preferable to allcaps because at least they eliminate the shouting effect of allcaps acronyms. In this era of proliferating acronyms, unless we want our text pocked by shouting allcaps acronyms or whispering pseudo-smallcaps, we need to choose typefaces that include the capacity to properly render all three cases of English, and we need to choose document formats that preserve our typeface choices.

Fourth, likewise, when acronyms like VISTA appear in boldface, the preferred capitalization is boldface smallcaps; when in italics, sloped smallcaps are preferred. In either situation, when smallcaps are unavailable, bold or italic allcaps, respectively, are acceptable if not optimal. Very few typefaces include true sloped smallcaps, but given their importance for setting text that includes both acronyms and italics, it is worth choosing one of those typeface for such text; very few support bold smallcaps, even fewer support both bold smallcaps and sloped smallcaps, and only very unusual typefaces (like Optima nova) support both those and bold-italic smallcaps. The OpenType font revolution is increasing the availability of such typographic features but still has a long way to go to reach the full needed range of features to gracefully handle acronyms in all text situations.

Fifth, given the use of smallcaps to handle acronyms with the goal of achieving textural compatibility with lowercase, I follow another guideline I have seen no one else advocate: capitalizing the initial letter in an acronym when it would have been capitalized had the word been lowercase, such as at the beginning of a sentence, at the start of a quotation, when set amid titlecase unabbreviated words (such as certain titles, heads, and subheads), and so on. It completes the blending of acronyms with unabbreviated words to have them both follow the same rules for capitalizing the word, and is certainly less disruptive than either reverting to allcaps or to remaining strictly smallcaps in situations that cry out for an initial capital.

After all this discussion about capitalization, some of you are wondering "Why bother? Who cares? It's just nitpicking. Don't sweat the little stuff." The answer is that you care, whether you realize it or not, for three reasons.

The rules of capitalization evolved to reduce the strain of reading, which is after all an unnatural act. Through trial and error, we learned that lowercase roman is easiest on the eye, and the other cases and styles need to be used sparingly, especially uppercase, each to perform its own specialized modification of the text. The proliferation of acronyms has increased the irritation of reading text in which they occur, like little pointless shouts, overly mannered and exaggerated. Proper use of smallcaps with acronyms helps soothe that subtle irritation, and after all, we do not particularly want the name of our software to be irritating if we can help it.

Also, the rules of good manners evolved to reduce the strain of interacting with other human beings by having them show you little courtesies in any interaction, a show of respect, like spelling and capitalizing your name correctly. If others cannot be bothered to get your name right, it means they do not respect you enough to make even a minimal effort at courtesy, so any further interaction would be a waste of your time. If, on the other hand, you cannot be bothered to get your own name right, well that leads to my third point:

Finally, sweating the little stuff distinguishes engineers from civilians. The craft of engineering is the art of achieving a big-picture accomplishment by attending to all the small-detail steps correctly. If engineers did not sweat the little stuff, you would be dead many times over by now. If we care enough to get the details right in our engineering, then it behooves us to get the details right in our communication so that we correctly convey to our audience our passion for excellence and our attention to detail. There's nothing like misspelling your own name to make others wonder if you really know what you're doing.

Sincerely yours,

Rick Marshall
Executive Director
VISTA Expertise Network

Postscript: For a fairly extensive listing of all the vistas out there, check out Wikipedia's page at en.wikipedia.org/wiki/Vista.

VISTA

2007-04-28T15:47:00.000-07:00

Dear Reader,

The subject of this weblog, VISTA, has no name. The name "VISTA" names part of this subject for part of its time, but it does not name all of it nor even most of it, and it has not always been the name of that part nor even for most of its history.

In the beginning it had no name. Amazingly, those who fought their David-and-Goliath battle to bring VISTA to the world merely described it rather than naming it, almost unthinkable in this era of branding urges so powerful we had to coin the term "vaporware" for our empty software names. Instead, the fathers of VISTA offered us abundant anonymity, a wealth of medical informatics with no name.

Ted O'Neill and Marty Johnson, two of the fathers of VISTA, called the software their team built "MUMPS systems," since they were written in the American National Standard (ANS) dialect of the Massachusetts General Hospital Utility Multi-Programming System (or Standard MUMPS, now also referred to as Standard M); they also referred to them as the "VA MUMPS medical systems." They also called the various VISTA packages "hospital-based programs," to distinguish them from the programs developed by their central-office competitors, the Office of Data Management and Telecommunications (ODM&T, also called "the enemy" by the brave hardhats of those lean years). The hardhats sometimes referred to their work as "committing portability," again to distinguish their work from the vendor-specific, nonportable software created by the ODM&T bureaucrats. Sometimes they referred to their work as the "DM&S systems," referring to the Department of Medicine and Surgery (comparable to today's Veterans Health Administration, VHA) within the Veterans Administration (VA, today's Department of Veterans Affairs) and thereby to their own work created by DM&S personnel to meet their own needs. The DM&S office Ted, Marty, and the early hardhats worked out of before being driven underground was called the Computer Assisted Software Staff (or CASS), so sometimes today we refer to their work as the "CASS system." Although CASS was a centralized office within DM&S, most of its developers worked remotely in the field at VA Medical Centers, so they often referred to their software as the "field-developed systems" or the "DM&S field-developed systems." The generic term Marty Johnson used as the subject of his historic June 10, 1981 memo was the "DM&S Medical Information Systems," and he described the emerging MUMPS medical applications as making up a prototype "VA Health Care Information System" (HCIS).

Today, the terminology needed to describe the approach they used has become much richer—eXtreme Programming, rapid prototyping, user-driven development, open-source development, and on and on—but at the time their work was original enough that their theoretical framework was described in terms of the papers, memos, and studies that guided them to attempt what they did. At the time, they often used the general term "the VA approach" to sum up their strategy, though that has to be understood as in contrast to "the official VA approach" of expensive, vendor-dependent, piecemeal juggernauts created by ODM&T. The absence of a name compelled them to discuss and consider the significance of what they were doing, leaving them rich in understanding but poor in such public-relations tools as branding.

In 1982, the VA rebranded the VA MUMPS systems as the Decentralized Hospital Computer Program (DHCP), and in 1996 re-rebranded them the Veterans Health Information Systems and Technology Architecture (VISTA). Sometime in the 2000s, VA re-re-rebranded the system HealtheVet (pronounced Healthy Vet), and then later re-re-re-rebranded it HealtheVet VistA (or HealtheVet-VistA, the punctuation varies), with an additional re-re-re-re-rebrand aimed beyond the VA called HealthePeople-VistA.

The VA's version of VISTA is just one dialect of a family of related medical information systems all ultimately derived from the CASS team's work. When the U.S. Indian Health Service adopted VISTA, they named their revised version of it the Resource and Patient Management System (RPMS). When the U.S. Department of Defense adopted VISTA, their revised version of it was named the Composite Health Care System (CHCS). The Finnish consortium that adopted VISTA before even the VA did named their version of it MUSTI. The Nigerian consortium that adopted VISTA named theirs the Made In Nigeria Primary Health Information System (MINPHIS).

When WorldVistA began working on VISTA outside the VA, they called their work OpenVistA, the name that the Medsphere Corporation copyrighted and made their own. When the U.S. Department of Health and Human Services (HHS) launched their initiative to make a free version of VISTA available for clinics and doctors' offices, they dubbed their version VistA-Office EHR, and that is the version for which WorldVistA now has responsibility.

There are more dialects of VISTA than this, and more names, but surely this is enough to understand why there has been a backlash against this balkanization of terminology and against the VA's passion for rebranding. The community has embraced the name "VISTA" reflexively, out of resistance to this pointless confusion, in an effort to nail down a coherent, sufficiently embracing identity for this vital legacy of software and culture. It is not good enough, not complete enough, does not clearly enough put its nominalist finger on the core of that identity, and it has to struggle against the partly negative, obscurantist intentions that led to that rebranding, but it partly transcends these things, has a positive enough connotation, was coined by worthy and well-meaning people, and in the end above all, VISTA is a good enough name for us to build our identity around. So we have.

Sincerely yours,

Rick Marshall
Executive Director
VISTA Expertise Network