For instance a programmer uses home-made linked list. He doesn't know that component was not tested. In some situations the insertion of an element causes a software failure. The programmer should invest a lot of time to understand the cause. After many attempts he finds, that due an internal error he must allways call function ClearAll() after creation of an empty list. Generally seakig this situation is not valid, but as rule it won't be corrected. The error becommes "feature of use" and the programmer becomes the guru.
One other example are assumptions about future use. For instance a developer writes a function with two parametrs of type short integer. He decides that variable of type short integer is big enough to hold some internal result of multiplication of these parametrs. In some real situations the parameters may be big enough to make the result of multiplication greater as permitted. The computer cannot represent this result and truncates it. The software gets a rare failure the cause of that is be very complex to find.
As rule an user cannot easily get the information about unexpected effects. The information about internal assumptions is usually hidden too. Only one way to obtain the information is to get a software failure and to find the cause. This is analogous with passage thought a dark room. Let's define it as user's dark of the source code.
This kind of darkness is a good home for the Dragon of The Source Code. The user's dark is the orfigin of many greal loses. The most known are Y2K problem and Arian 5.
We'll consider this darkness more detailed lather. Let's describe the third way to use source code.