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

Mike, It seems that Timothy and yourself are arguing about two entirely different scenarios - in fact I can think of 3 basic situations: 1. A stable business environment supported by stable code (what Timothy describes) 2. A rat's nest of changes (what you describe) 3. An evolving business environment supported by evolving but properly maintained code (i.e. reviewed and then modified or re-written as required) Yes, I agree 2 calls for the treatment you suggest - irrespective of whether or not there's a platform upgrade! In situation 1, however, I agree with Timothy - if it isn't broken, don't fix it! The same is likely to apply to situation 3 also. I was recently involved in a less drastic upgrade, 4.12 to 7.22 engine, 4.11 to 6.whatever's_current tools. There had been two teams maintaining different sets of applications. One had proper control of their code and made the migration bang on schedule. The other hadn't and didn't. I think that the best advice to Darrly is to evaluate the situation. If you think the code is stable, recompile and test. There are some issues which people have suggested and you may well find that some SQL needs to be amended because the optimiser handles it differently. If you think that the code's a mess then you should certainly consider Mike's approach - but you will have to trade extra time and costs against the reduced risk of failure. Ian Mike Segel wrote: > > 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