http://perso.club-internet.fr/cthibaut/refactoring.jpg

This is the DesignDebt dynamics roughly sketched in diagram of effects. 

	* Ellipse represents a measured phenomenon.
	* Clouds represent a measurable, not actually measured phenomenon.
	* An arrow from A to B means : A increases B.
	* An arrow with a gray dot means : A decreases B.
	* Two arrow from A and B joining before C means : A and B have a multiplicative (non-linear) effect on C.
	* A white square means A effect increasing B effect depends of management action.

''(Source for the diagram notation : QualitySoftwareManagement.)''

In any attempt to describe the DesignDebt to people who are not very familiar with the non-linear sides of software development, the hard part is having the mere existence of such a DesignDebt acknowledged. Other points made in order to resist to or deny the DesignDebt effect include:
	* Escaping the debt: This change will be the last, so we won't have to recover the debt in the future. 
	* Confusion with TurnOver effect. We'll keep the same people on the work so the debt will not be so high after all.
	* Borrowing more: We need to get the job done, not the perfect design quality.

-- ChristopheThibaut