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
