VISTA Enterprise Network - Successful Implementation, World Class Support

Friday, October 24, 2014

Database Elements Problem 2: Version Control of Init Routines

For VISTA hardhats, here's the latest post in my series introducing and explaining the OSEHRA Forum project.
"If the answer so far to the question "What is VISTA made of?" is only the tip of the iceberg when it comes to the complexities introduced by non-routine software elements, what else makes up this iceberg?
"Flattening data and definitions into Init routines might result in convenient, flat structures (routines) that lend themselves to version control, but the purpose of these routines is to regenerate these data and definitions at the destination VISTA systems, not to support version control. An Init routine is not a snapshot of a file; it is software that regenerates that file in another VISTA system.
"If our goal is to keep track of the Init routines for their own sake - and that is one of our goals - then loading them into Git or other version-control repositories makes good sense. If, however, our goal in so doing is to successfully version-control the data and definitions they transport, we're in for numerous disappointments. . . ."

Wednesday, September 24, 2014

Future VISTA: A Technical Townhall

VISTA Expertise Network executive director Rick Marshall gave a presentation at the 2014 OSEHRA Open Source Summit called Future VISTA: A Technical Townhall. This session, intended for experienced VISTA developers, addressed priorities for technical development within the VISTA EHR. Topics included the code convergence challenge and a new proposal for broker consolidation. The presentation can be viewed here:
Part I
Part II

Thursday, August 21, 2014

VISTA and the Agile Manifesto

VA's early adoption of the Agile methodology (before the term Agile had been coined) led to remarkable accomplishments and extremely high customer loyalty.

For organizations that contract out much of their software acquisition and development, it can be extraordinarily difficult to stay true to the Agile methodology. Likewise, the more organizations try to get their software acquisition and development under control - as is required to manage contractors - the more they risk letting processes and metrics replace the Agile methodology.

As VA charts its IT course into the future, and as our new Secretary of Veterans Affairs comes to grips with his organization, we can all benefit from a deeper understanding of what Agile is, why it leads to the successes it does, and how contracting and business processes can conflict with or suppress Agile's productive capacity.

VISTA hardhat Sam Habiel introduced me to the best resource I've seen on the subject so far. It is called the Agile Manifesto (http://www.agilemanifesto.org). It is very short, just two pages. The first page is only a few lines long. I quote it here in its entirety:

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan 
That is, while there is value in the items on the right, we value the items on the left more.
This short statement encapsulates how VA revolutionized itself with VISTA, by creating Golden Pairs consisting of programmers and medical practitioners who worked together doing medical-software R&D, letting the discoveries, the experimental evidence from trying things out together, shape the organic and extremely rapid evolution of world-class medical software.

The second page draws out some of the important implications of that terse manifesto, in the form of twelve briefly stated principles:

Principles behind the Agile Manifesto
We follow these principles: 
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 
Business people and developers must work together daily throughout the project. 
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
Working software is the primary measure of progress. 
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 
Continuous attention to technical excellence and good design enhances agility. 
Simplicity--the art of maximizing the amount of work not done--is essential. 
The best architectures, requirements, and designs emerge from self-organizing teams. 
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I encourage everyone interested in helping VA achieve the most from its healthcare software to learn about and spread the Agile Manifesto. This brilliant and concise frame of reference could help VA shape its next generation of IT policies in the most productive directions, to increase our ability to improve healthcare for humanity.