Re: Porting 4GL Version 2.x To 6.x

Timothy M. Hood wrote: > > Mike Segel wrote: > } > } Darryl Priest wrote: [ME] > } Yeah, > } Do a code review and most likely re-write it. > } I recommend this for two major reasons: > > I disagree. See below. > } > } 1) Earlier versions of Informix had bugs and you had to implement > } work arounds. These work arounds could have slowed down the > } program and have added to overhead. > } > > I can't think of problems in 1.1/2.1 that were significant enough that > any code work-arounds are that big of a deal. Also, considering those > work-arounds (and whatever theoretical performance hit is taken) have > been lived with, this is a non-issue in light of the performance of the > new machine. > Uhm, I hope you don't call yourself a software engineer. To give you an example, I got dumped on a project, where several people had earlier been dumped on that project. I inherited several peoples work of quick fixes. The problem was that they didn't solve the real problem. So, I had a birds nest of code. While this analogy doesn't completely fit, the point was that I had a patch set of code which marginally worked. Rather than add yet another of patches, it was cleaner and simpler to rework the code. Smaller code, faster operation, less memory hence less of a load on the system. > } 2) You are talking about a 10 year old platform. Perhaps your > } business rules have changed and the program should be looked > } at. > } > > I've got clients that are still using unmodified programs I wrote in > Informix 1.1/2.1 some 10+ years ago. Their business hasn't changed, and > they don't feel the need to spend (read: waste) money updating. That's > fine. > Uhm, you really are not helping to make me want to hire you. Tell me oh wise one, what happens when you have software, 10+ years old, and considering that the average lifespan of a programer at a job is 2-3 years? Who is left who knows exactly what is supposed to happen? What happens when you don't have the support staff capable of maintaning your software? Oh, I see, you want them dependant on your skillset so that they will have to call *you* for support. I can tell, you are not a software engineer. Nor have you worked on a multi-year multi-member team where you see the advantages of code reviews. Of course, Informix's 4GL has changed over the years, new features and functionality built in to the libraries. > If the company has taken the posture of making the transition cost as > minimal as possible, then it does not make sense to re-write the > software. Might as well change the whole client/server paradigm to what > works best for them then. It is possible for software to have a long > life expectancy. Gee are we talking about long term cost savings? Or the up front cost of doing a hack. Sorry if this seams caustic, but Tim, I made a few simple suggestions which follow simple software engineering guidelines. Your suggestions will end up costing the client more money in the long run and require an unnecessary dependancy on you. Based on my experiences in multiple environments, a code review actually reduces the cost of software in the long run. Just a few tips from your Uncle Mike. -- #include <std_disclaimer.h> /* Mike Segel (MS385) */ #include <No_Spam.h> #ifdef OFFENDED_BY_CONTENT The author takes no responsibility for this post. Any resemblence to a coherent rational thought is purely coincidence. -The Management. #endif