We dig closely to roots. There is one other kind of information about reasons. All decisions are chooses between many possibilityes. This is a tactic of strategy. Such information describes how the question why was answered. The next level describes which possibilities were considered and which were unknown. The next tells why certain possibilities were presented and other werent. To climb from the origins to the given results we need answer the questions:
Unfortuanately it is not possible to answer these questions in the opposite direction. If we have only an unit of source code, we know what it makes. We can only guess what it should do. We cannot determine requirements examining design. We cannot decide are reguirements correct or not, if we don't know the problem domain. If we know only a number of problems problem, we cannot decide how important each of them. If in documentation stands only "The problem X is important", we don't know why and for whom. The deeper we dig the more complex to answer the questions. This process is definitely dark.
Of course the root of decision is not necessary, if this decision is correct. However in many cases the decision is bad and this information is needed to understand this fact.
If a developer must correct an error, he needs to know:
If a developer hasn't got answers on such questions, he must make assumptions. The worst problem is that he need not only find other possible variants, but also to guess which from them the previous developer knew.
Suppose a developer has found a function, which uses bubble sort. This developer knows that quick sort is better. The autor of the function may not knew about other algorithms. This seems strange. The developer must waste time to check other presuppositions, even the first is right.
If the situation is more complex, many results of a correction are possible. For instance:
The second developer may be not the last. Many people can change a code unit. Not always the reasons of changes are clear. In such cases some parts of the code getting his own life. Nobody knows what they are developed for. Nobody knows why they are developed in such way. Nobody can predict the results of changes. Let's call this nice phenomena "source code phantoms".
Frequently the origin of phantoms is the conversion from an other language. Each language has his own tricks. If a such trick was implemented in an other language, a good puzzle is waiting for the future developers. We can mention automatically codegeneration. In many cases generated code is a good gift for real puzzle fans.
There are more other methods to add dark for the developer. The widely used are ambiguous names, wrong comments and partially implemented units. Sometimes copy-paste operation produces very interesting effects.
The lost information give the developer a good training for his brain. We'll consider many sources of the dark later. Now return to The Dragon.