Fair enough. I don't think anyone (certainly not me) means to imply
that VistA was poorly designed. As you point out, thee are trade-offs
between modularity and memory footprint. But regardless of whether or
not the design of VistA (then DHCP) made sense at the time, the lack of
modularity is definitely a problem today.
====
Gregory Woodhouse
[EMAIL PROTECTED]
On Apr 4, 2005, at 8:48 PM, Chris Richardson wrote:
Rodney;
I read the article with interest. There are some major issues with
the
current VistA model (this does not invalidate the data structure or the
current release. What is so great about MUMPS andVistA is that we can
be
developing a new VistA complete with re-engineering and maintain the
existing model intact. We just need to use a different namespace for
the
new improved model. There are key calling points which must be
honored, but
the task in parallel is certainly doable when there is a reference
model
close at hand. Now, why go do all of this?? Here are three good
reasons;
1) Original VistA was written for machines with minimal stack depth
so
much was comunicated between modules through the symbol table and then
a
GOTO. a) This meant flat stacks, but lots of duplicate code which
could not
be re-used. b) lots of detritus in the symbol table
2) Most of VistA was written to optimize for a routine buffer scan
rather
for a pre-execution LABEL Table. This means that many of the early
VistA
code was written upside-down (much of this has been replaced, but
vestiges
survive) so that the most frequently called labels were found early in
the
scan.
3) The MUMPS Language had moved forward and supported argument
passing,
symbol-table scoping, and much deeper stacks. This results in fewer
symbols
in the symbol table at any one time. With good symbol table
management,
there is less likelyhood of unimplied synergy (detritus left over from
other
executions perhaps with no correlation to the current activity.
There are more, but I have to catch a plane in the morning.
Best wishes; Chris
----- Original Message -----
From: "HITS" <[EMAIL PROTECTED]>
To: <hardhats-members@lists.sourceforge.net>
Sent: Monday, April 04, 2005 8:06 PM
Subject: RE: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
Let me jump in here for what it is worth. Rick and I had a
conversation,
oh, about three years ago where we re-designed the architecture of
VistA
in
my office one day. This would require a complete re-engineering of
business-rules and interface architecture which would necessarily
require
complete re-coding of all VistA routines (I can hear the groans from
here).
But this, IMHO, is exactly the point. Somewhere along the line we
have to
bite the bullet, redesign the system to allow for unlimited
expansion, and
then migrate the data to the new system. It isn't going to be easy,
and
it
isn't going to be done in a year - maybe in five, more like ten. To
me,
this type of undertaking should be one of World Vista's top
priorities,
but
that's another discussion.
Of course, we could always migrate everything over to Oracle with a
Java
front end...
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Gregory Woodhouse
Sent: Monday, April 04, 2005 7:57 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
====
Gregory Woodhouse
[EMAIL PROTECTED]
On Apr 4, 2005, at 9:30 AM, Greg Kreis wrote:
Gregory Woodhouse wrote:
Gee...I usually agree with him on software engineering issues, but
it
strikes me as rather odd to say that rewriting code from scratch is
the worst thing you can do because it is harder to read to code than
to write it. From a business perspective (i.e., time to market and
such) he has a point -- in the short term. But in the long term, the
growing maintenance and extensibility problem of old, patched and
many times re-patched code will always come back to bite you.
Aren't you describing any of the major software products from most
companies? I don't know if any are complete rewrites, but I can't
remember one trumpeting that fact. They all talk about features.
After all, the nasty stuff is our job as programmers... ;-)
Oh, I don't doubt it for a moment. But a problem is no less a problem
if it's everyone's problem. More to the point, rather than saying this
is "par for the course" (and it is), shouldn't we be asking how we can
do better?
I think that one thing we are all coming to appreciate is that
adapting VistA to new situations, or simply extending it, is no easy
task. Why? We can argue that an EHR is a complicated animal (and it
is), but it is much harder than it should be!
I would guess that is mostly due to the architecture. In the last
twenty plus years, software and hardware advancements have been so
dramatic that we can architect at ever smaller levels. This permits
new ways of building that one could only dream of in the 80s.
Imagine
what kind of buildings you can create if you have materials as light
as aluminum, many times stronger than steel and cheap. Finally, stir
in standards, so you can buy interchangeable parts (at least
advertised so... ;-) at a decent cost. Would that make an architect
think differently?
I'm not sure if I quite understand your point here. Certainly it is
true that architectural advances in the area of hardware have been
dramatic, but I'm less sure that this is the case in the area of
software. But more often than not, what counts as architectural
advances in software is just new ways of packaging the same ideas. A
possible exception is in the area of operating system design, where
significant advances have been made at a fairly steady pace. Compiler
design has also been an area of progress, but language paradigms,
basic
algorithms, and the like, have progressed very little.
I agree with the last few paragraphs of this article where he argues
that the types of problems he describes are symptomatic of
architectural problems. And in that sense, I agree with a caveat:
simply rewriting your code is likely to be an (expensive) exercise
in
futility -- unless you address the architectural shortcomings of
your
code in the "rewrite". So, okay, maybe Joel is right that rewriting
code is a major strategic error, but I would argue that failing to
write new code that adequately addresses the shortcomings of the
existing code base is equally a major error.
But what he didn't address was making a major technology change in
the
process. He seemed to be talking about rewriting for the same
platform, probably with the same software technology. What if you
feel
you must rewrite to move to a radically different technology? Some
might argue that the reasons given for the move are not sufficient to
dictate such a drastic step, but forget that for the moment. Presume
you agree with the idea. You would have no choice but to rewrite.
But not the entire thing from scratch. Do it in well controlled
phases, right?
That was my impression, too. When I spoke of writing "new" code rather
than rewriting existing code, this is basically what I had in mind. I
agree that re-working code in well controlled phases is certainly a
workable strategy, and I believe that there has been a tendency to
simply give up on this approach in the face of bad experiences with
encapsulation or whatever one chooses to call it. In my view, the
problem is that we've been a bit too myopic, often trying to
mechanically translate call level interfaces into HL7 messages (say).
The problem is that moving from a centralized to a distributed
architecture necessarily requires a different way of thinking. One
thing I have been preaching is that timing is just as important as
bandwidth. Think about hardware: How much slower would our computers
be
with no memory cache? No pipelining? If ALU operations can never be
started in parallel?
I am wondering how the introduction of Cache at all the VA sites is
going to effect VistA. Cache offers many, many more features for
software re-engineering than they had with DSM. So, will the
national
re-engineering using technology like Oracle and Java find itself in a
race with local sites and VISNs that can extend M with the
SQL/Java/Objects/XML support in Cache?
Interesting times.... ;-)
This is certainly an interesting question. I believe Cache features
could certainly be used to advantage. I would hope that an important
driver in the decision of whether or not these features should be used
will be the extent to which they are needed. In the past, we've
successfully encapsulated platform dependencies. That may be too much
to ask for something like Cache objects, but surely if we decide that
there a significant benefit to using Cache objects (say), then we can
ask how to make use of this feature safely.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
