What is the present # of lines of code on a mainframe that a programmer can identify (and fix?) using the best of the software for this purpose? I realize this is an approximation, but I need a number for a presentation I'm making the morning of Nov. 6.

Does anyone know how many days- (weeks- ?) worth of food is incountry at any one time?

Thanks loads, mdhiskey

-- Marydel Hiskey (mdhiskey@lanminds.net), December 04, 1998

Answers

I work for a software company with a tool that is used for mainframe COBOL and PL/I. We figure that, with optimal conditions, an experienced programmer using our tool can remediate 1 million lines of COBOL in a month. This means finding the dates with 99+% accuracy, and either expanding or windowing each date. This does not include testing.

This is COBOL only. There are no software tools for Assembler, which must be done manually. There are no real tools for the 4th generation languages (FOCUS, DYL280, EZTRIEVE). I have seen tools for C, but I do not know how well they work.

-- Fran (fprevas@ccdonline.com), December 04, 1998.

The efficiency of remediation depends on many factors besides the increasing proliferation of useful automated tools.

These include adherence to coding standards, use of standard libraries, archiving practices, data dictionary usage, documentation standards, variable naming conventions, variety of languages used, familiarity with the code base and business practices and requirements, commenting standards, and many more.

If rigid but reasonable standards have been enforced, remediation can go very quickly. If not, the process is slow and extremely error- prone. The difference between extremes can be a factor of 100 or more in the time required and the quality of the repairs.

I've been handed code written in languages I've never heard of, without a single comment or line of documentation, with no idea of what the program does or why it was written, and been asked to make extensive enhancements. And I was thankful that the source matched the production code, and that there was source code at all and I didn't have to reverse-engineer the object code. These projects went slowly, but could have been much worse.

-- Flint (flintc@mindspring.com), December 04, 1998.

Of all the things I have hated in this world, coming in after some other programmer and cleaning up his mess has got to be number one.

-- Paul Davis (davisp1953@yahoo.com), December 05, 1998.

# # # 19981205

Hello, Marydel,

( I love _that name, BTW!! )

The direct, albeit generic answer to your question:

Average programmer can productively remediate ( identify, change/fix, test and implement -- move into production ) about 100,000 LOC ( Lines Of Code ), PER Programmer, PER Year!

That's the stat we use in our Y2K projects. This is virtually universal; tools, or no tools. Even with tools ( i.e., "intelligent" parsers ), each and every LOC must be suspected and inspected. Creative programmers have created Byzantine code ( land ) mines in a lot of legacy code over the decades. ... One of the first _unbelievable_ ''lessons learned'' doing insipid remediation work.

There was, and still _is, a mentality of creating "spaghetti" code ( most of it undocumented or poorly documented ) for job security. I've always found this prevalent attitude disgusting and counterproductive. ( Poor management, again, accounts for much of their own cost overruns and ridiculous maintenance! )

This practice will ( should! ) definitely die a long overdue death with the Y2K Techno-Ambush. Management that permits such practices should be fired, on-the-spot, no questions asked, presently and in the future!

... MHO!

Regards, Bob Mangus # # #

-- Robert Mangus (rmangus@mail.netquest.com), December 05, 1998.

Rob - even worse are the managers who actively encourage non documentation of code by not allowing enough time in the system development for code documentation. A good job of documentation takes about as long as writing the code - a sketchy roadmap on paper with lots of references to comments in the source code takes at least a fourth as long as writing the code. I gave up trying to document everything for the idiot bosses years back and just wrote a roadmap of what the code is for into the source code itself. Some places you are lucky if you can even do that! Now ask me why I switched over to networking.

-- Paul Davis (davisp1953@yahoo.com), December 06, 1998.