Having a little experience with VistA and CHCS, there is a reason why VistA has stood the test of time. I have seen the VistA process from the contractor side and from the VA side. The VistA experience is very different than most products. The Archetypes discussions are interesting, but reductionist, ignoring the dynamism of the actual working environment. Part of the reason that VistA has succeeded where commercial approaches fail is because VistA was developed first by area knowledge specialists who had to live with the results, so they got it working and then had to add or adjust functionality.
Adding the programmers in a development cycle environment just adds delay, a lot of delay (sometimes months and years to make just a single line of code). When the knowledge area experts are the users, the requirements evolve quickly and are implemented by the experts or the programmer with the knolwledge domain expert as an active participant in the process, minute by minute. There are some significant granularity problems with the totally table driven approach. This is the primary fallacy of the Relational Model. It is idealized with beautiful rhetorical arguments that seem entirely logical. That is until an ugly real fact comes along to knock that beautiful logic into a cocked hat. This is why creativity and the dynamics of reality has never been successfully mechanized. The answer is to use that which is effecdtive in the specific application. The goal is to take a copy of the system developed by the knowledge area specialist and give it to the programmers to document and optimize and build effective tools to aid in the process. Oh well, let the rebuttals begin. ----- Original Message ----- From: "Greg Woodhouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 10, 2006 3:50 PM Subject: Re: [Hardhats-members] Software Archetypes - single vs double systems > > > --- Jim Self <[EMAIL PROTECTED]> wrote: > > > > > I spent quite a bit of time studying it but I haven't looked at it > > for a few years now. My > > general impression was that it was very interesting and far thinking > > but too academic to > > be of practical use to me as a systems developer for a long time. It > > was also too complex > > for me to be able to give back much in the way of valuable feedback > > on it without devoting > > much more time to it than I could spare. > > I don't know that being "academic" automatically disqualifies it as > being practical. Nevertheless, I do share the sentiment -- at least to > an extent. It is awfully easy to get so caught up in abstractions and > theoretical matters that we lose touch with the day to day reality of > building practical systems. But there is an opposite danger, too, and > one to which I think we are often prone, and that is, of course, > ignoring matters of great practical importance because they seem overy > acadamic or far removed from what we normally think of as practical > matters. > > In the case of archetypes, well, I don't know. As soon as I can, I'll > read the message Thomas Beale just posted to OpenHealth, and I hope > I'll gain a greater appreciation of archetypes. But in some ways it > reminds me of languages I've studied with some enthusiasm hoping to > find important or exciting ideas, only to find more complex ways of > expressing the same old familiar ideas (with all, or many, of their > flaws). But I've had the opposite experience: I've worked my way > through new (to me, at any rate) programming languages and found that > they DID include exciting and useful ideas. (I'll leave it as an > excercise to the reader to speculate as to what some of those languages > or ideas might be.) So far, I remain unconvinced as to the value of > archetypes. Indeed, I'm not really sure I understand what archetypes > are meant to be. But it does seem clear enough that they have been > proposed in response to a real problem: one that has long plagued VistA > (and probably just about any other EMR), namely the embedding of domain > knowledge into code primarily concerned with the operational details of > an application. That is detrimental not only to reusability and > maintainability of code, but such basic things as consistency and > reliability. > > > > I think it could benefit greatly from knowledge derived from VistA > > and perhaps vice versa. > > Having already written more than I intended to, I'll only add that I > wholeheartedly agree. It would be interesting to see how some of thesxe > ideas might be implemented in the context of VistA, and perhaps what > there already is in VistA that was put there to address precisely the > same problems archetypes are meant to solve. > > > > > --------------------------------------- > > Jim Self > > Systems Architect, Lead Developer > > VMTH Computer Services, UC Davis > > (http://www.vmth.ucdavis.edu/us/jaself) > > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > "It is foolish to answer a question that > you do not understand." > --G. Polya ("How to Solve It") > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
