× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




I don't think that ROI is the problem.
Most companies, and specially IT managers, want to avoid risk.
It's better for them to spread costs over a long period (maintenance) which is not very visible to upper management instead of taking the risk to rewrite the app.


From: Jerry@xxxxxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Date: Tue, 26 Aug 2008 09:01:53 -0500
Subject: RE: What should I say to a *nix community?

I did this for years for (what should have been) a simple invoice print program. That is, whenever "new" stuff was needed, used CALL's to RPG IV pgms. It got so convoluted from both the original poor design and, then, from my mods. Eventually, they wanted a change that simply could not (for 100% of the test cases) be shoe-horned into the existing mishmash. At last, a golden opportunity (excuse) to re-write it the way that (even in RPG II) would make more sense.

I once worked for a company where the core program was a 3000+ mainline program with illogical (i.e., confusing, hard to follow/comprehend) GOTO's. When it bombed (on average once a week; twice in the busy season), it took two people to debug it. I once suggested to my boss (he and I were usually the ones that had to debug it) that the best thing to do was put a match to it and start all over. He wouldn't here of it. Later we started a new company that needed the same function/program. Fortunately (!) we couldn't shoe-horn the new company into the old code. It took me a week to design and flowchart it, a week to code (in II). In the next three years it crashed once. Took us two minutes to find and fix it. We spent much more than two weeks debugging the earlier monolith; keeping it was a false ROI. I know that ten years after I left the old spaghetti-coded piece of c**p was still in production.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of PaulMmn
Sent: Tuesday, August 26, 2008 7:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: What should I say to a *nix community?

Some truly ugly code is like... well, it's so ugly that it either
should be scrapped, rewritten, or propped up so it keeps working.

Hoops?? I'd be willing to build a wall of 'custom interfaces' around
that piece of code to avoid having to touch it! I'd be willing to
burn my RPG debugging templates to avoid having to touch it!

This is -result- of "most software is continually modified." By
people who didn't understand the program, and just patched the 'bad
parts.'

The problem is that if it works correctly, and if it is truly ugly,
it is dangerous to The Company to monkey with it.

That piece of ugly code is likely -filled- with important business
logic! Ideally, the logic should be extracted into a nice,
streamlined, well-designed, well-written, well-documented, easily
maintained module, that can be called from any program that needs to
use that logic. And that's one of those "Major Projects" that's nice
to dream about, but we -really- "need" to add that GUI interface to
the order entry system first...

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx



At 8:16 AM -0400 8/26/08, Charles Wilt wrote (in part):

But most software is continually modified, thus there is indeed an ROI
for rewriting to make use of more modern and easier to maintain
techniques.

Imagine the ugliest piece of code you have to work with on a
periodic basis....

How much of a headache is that? How many hoops are you willing to
jump through to avoid having to change that legacy code.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


_________________________________________________________________
De leukste online filmpjes vind je op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nl

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.