Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
Excellent articlethanks!!! steven mcphelan wrote: I thought you might find this article interesting. http://www.joelonsoftware.com/articles/fog69.html --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
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. 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 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. Gregory Woodhouse [EMAIL PROTECTED] On Apr 4, 2005, at 7:20 AM, steven mcphelan wrote: I thought you might find this article interesting. http://www.joelonsoftware.com/articles/fog69.html --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
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... ;-) 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 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? 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 ;-) Gregory Woodhouse [EMAIL PROTECTED] On Apr 4, 2005, at 7:20 AM, steven mcphelan wrote: I thought you might find this article interesting. http://www.joelonsoftware.com/articles/fog69.html --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
Dear Steven, It is in the subtle points he makes that I agree most. For example, he is not arguing that we should never clean up code, rather that we should lower our expectations of good things to come and raise our expectation of problems. For example, while I worked on TaskMan I probably refactored it about six times, some parts more than others, but I never threw out the original code and started from scratch. I always started with the code as it was and began commenting, reorganizing, and so on in place, preserving all the logic intact but modifying its expression. The more times you have done this with a specific routine, the easier it is to do it again, but only if it is the same individual doing it. When we move programmers around from project to project, we lose this ability to easily refactor routines in place. When you refactor a program in the same language, you can do it gradually, preserving the logic. When you rewrite it in a new language you cannot do it piecemeal, and the structure of the logic rarely translates as literally as it might at first seem because of the different execution and environment models. Of course, most people eager to rewrite have no intention of keeping the logic intact and their plans founder accordingly. I enjoyed this article and will use it in the VistA Programming session at the Boston meeting later this week. Thank you for calling our attention to it. Yours truly, Rick On Mon, 2005-04-04 at 07:20, steven mcphelan wrote: I thought you might find this article interesting. http://www.joelonsoftware.com/articles/fog69.html --- 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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
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
Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH
Greg; I think we are violently agreeing again. Absolutely, for the time it was written, and the levels of technology available. It is still great. But a lot of the hinderences that it was programmed around are long gone, and we can make the code smaller, more re-usable, and less surprising (unintended synergy). We need only re-evaluate. We have a working model that could be vastly improved for modern hardware and techniques. The proper tool for the proper job. What a concept.Chris - Original Message - From: Gregory Woodhouse [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 9:07 PM Subject: Re: [Hardhats-members] ARTICLE ON REWRITING CODE FROM SCRATCH 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
