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:
- There is a need to convert to a new system. In order to convert to the new system, the organization must delve into the logic of the past to see either how things ran or still run.
- There is a need to merge systems. It is difficult to merge systems when you don’t know what a system does.
- There is a legal reason to know what a system either does or once did. If you have to go to a court of law, you want to know what you are talking about. You don’t want to be responsible to testimony that is simply incorrect.
- There is a pressing need to go back and make changes to a system. It is dangerous to make changes to a system when you don’t know what the system does.
This short list merely scratches the surface. In reality, there are many reasons why undocumented old code is a corporate liability.
How difficult would it be to put together a documentation package? Indeed, when it comes to data, there often is reasonably good documentation. There are old dictionaries. Old repositories. Old copybooks. It is fairly simple to gather the data definitions that once existed. (However, this is not a perfect science.)
But data is only one element of older system documentation. There is the need to document processes as well. Stated differently, when you are trying to do old system documentation, focusing on only data is like one hand clapping. You don’t make much noise when only one hand is clapping. In order to create applause, you need two hands clapping. You need to document processes as well as data.
The long-term implications of programmers not doing documentation are now coming home to roost. The corporation is left holding the bag, and it is a pretty ugly bag.
SOURCE: Corporate Liability: Undocumented Code
Recent articles by Bill Inmon