The Importance of Project Management

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

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

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

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

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

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

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

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

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

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 find 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

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 flow 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

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. Configuring 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

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 fixes or enhancements. As the reports accumulate, the urgent problems identify themselves and do not require committees or expert panels to identify.

Many people find 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 find 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

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

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

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

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

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

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

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.