next up previous
Next: . Up: The Software Dragons (ErrorLog:Documentation:Introduction). Previous: Why the Dragons?

The bad decision and its role in a software project

Let's define a decision as bad, if one of the following decisions must be the opposite decision. This definition is pure theoretical. In most real situations we don't know what decision must be corrected. We cannot prove a decision. In case of a solution we may find a formal method to check it. There are no such methods to examine a decision. Usually there is a person who says that his own speculations are the correct proof. Unfortunately they aren't. The worst fact is that they cannot be.

For practical purposes we can use two following ``soft'' rules:

  1. If one decision is the opposite of one previous, this previous was probably bad.

  2. If a software project has fallen, some bad decisions had probably been made.

As you see we can form an estimate only for the decisions in the past. More interesting is that such estimation is a decision too. Consequently in the future we may detect that this decision was wrong.

It is wise to find a bad decision early. One decision implies some work to realise it and a number of additional decisions that imply additional work too. If the primary decision is bad, a part of this work was probably not needed to be done. This is waste of time and resources. We can define it as the cost of the bad decision. Of course if the bad decision was corrected before this unnecessary work was done, the cost of the bad decision is lower. Consequently we can speak about the potential and the actual cost of a bad decision.

One other interesting thing is the correction of a bad decision. Common practice is to make a big number of lower level decisions, where the right action is to come to an opposite decision of the same level. The economical reason may be the attempt to save actual cost of the bad decision. The political reason may be the ``polite valuation'' of the decisions being made by higher level management. In comparison to getting results in a right manner this leads to waste of time, money, product quality, etc. Let's define this difference as the cost of the crooked way. It is a part of the actual cost of the bad decision about the correction of one other bad decision.

We need a name for cost of developing software without bad decisions. Let's define it as the optimal cost. It may be possible to reduce optimal cost with some magic, for instance due ``good luck''. This isn't the subject of our article. We'll consider the possibilities to reduce the cost of a real project to reach the optimal cost.

Usually the optimal cost is less than the cost of the crooked way. As result the correction of the bad decision is more profitable. In some situations the opposite may be true. Let's define this as the stabilisation of the bad decision. Principally the stabilisation can be endless. This is usual for low level decisions. The high the level of a bad decision is, the quickly the cost of the crooked way rises. If a high-level bad decision won't be corrected, the potential cost of it shall be paid sooner or lather.

The interaction of bad decisions may be complex. For our purposes we need remember that it is not lineal. We can estimate the potential cost of a bad decision as lower or equal to the potential cost of the bad decision of the higher level. If a result of one bad decision is one other bad decision, the actual cost of the first can rise to its potential cost. Consequently we can say that a bad decision may save actual cost of one previous. It isn't good to believe in this. The opposite result is more frequent.



Subsections
next up previous
Next: . Up: The Software Dragons (ErrorLog:Documentation:Introduction). Previous: Why the Dragons?
2002-03-18