Oops! The input is malformed!
Originally published December 6, 2012
Real programmers donít do documentation. Thatís the way it has been since the first line of code was written. It was true for Assembler. It was true for Cobol, Fortran, C++ and Visual Basic. And it probably will be true for future languages even into the next millennium.
A programmer considers his/her job to be one of a problem solver, and some of the problems solved by programmers are worthy of a Sherlock Holmes novel. At the end of a program, when the testing has been done and when all of the output has been checked out, the demand for the programmerís attention is always high elsewhere. Documentation just seems to be left out.
Or on the rare occasions when programming and documentation has been done, the maintenance programmer fails to do his/her share. The maintenance programmer takes the old code, fixes whatever needs to be fixed, and is on to the next program.
One way or the other, old code arrives at the doorstep and no one understands what it does.
Making matters worse is that much of old code was written in technologies that are either not supported today or it is difficult to find anyone that can or will support them.
Try finding an available and enthusiastic programmer for Total, IMS, VSAM, CICS, System 2000 or Model 204. There are many languages and technologies of the past that simply do not have an active support audience today. And that is where much of the old code and system development of the past is.
Why would an organization want to delve into the code of the past? Some of the reasons organizations need to look at old code include:
Recent articles by Bill Inmon