Playing with my tablet I found myself sketching this diagram of effects, summarizing how tough is software craftmanship...

I have to ask readers to pardon me for showing out a diagram that violates even the basic 7±2 principle :-).
Maybe I could ease this picture readability by showing intermediate versions of the diagrams as they came out during its creation, adding bubbles in multiple incremental steps... but life is short! So I am going to the description of the 'whole picture' diagram.
Does it look complex enough? And it is just an over-simplification...
If you just look at the words within the clouds and the ellipses you will not see anything particularly interesting. The real substance of this diagram is not in its nodes but in the connections, in the relationships that the connections describe.

Diagrams of effects are a good expression of one of the core concepts of 'system thinking':
most of a system magics and complexities are not in the system components but in the way connected components interact one another and in the way the effects of these interactions propagate across the overall system internals.
Interactions between different systems and components are usually regulated by complex (non linear!) natural laws that even in the simplest cases can be foreseen only if we reflect on the dynamics of such interactions.

Diagramming this type of sketches helps in thinking and fixing about the dynamics of systems internals.
Only when the dynamics of components interactions become enough transparent and we have resolved any ambiguity than we can try to simulate and identify corrective actions that will likelyhood keep the system in control whereas wrong actions will instead have disastrous effects.

So, let's briefly explain the what and why about diagrams of effects....
These diagrams express dependencies (correlations) between measurable quantities.
Clouds represent conceptually measurable quantities, quantities that with some experience we can be able to compare but that in practice we will not able to quantify. Let's consider "software quality"...there is no unique definition of software quality and there is no single metric that can measure it, but people with some concrete background experience in software development will be probably able to compare the quality of different software modules or identify if a module quality degrades or improves with time.
Ovals represent quantities measureble in the real.
But while reflecting about systemic phenomenons, we are not really interested in the measures but rather in the way the quantifiable measures are related one another. A connecting arrow indicates that a variation in the source quantity will cause a relative variation in the target quantity, pointing out that there is some type of (usually non-linear) correlation between two or more phenomenons or two or more components interacting one another.
A simple arrow line indicates a positive effect: if the source quantity increases the target one will increase too; an arrow line with a black circle on top indicates a negative effect: if the source quantity will increase the target quantity will decrease.

An arrow with a square icon on top indicates a correlation being produced by a human control action; the human action can generate a positive or negative effect that we will respectively indicate with a white or a black square icon on top of the correlation arrow.
The idea is that we will eventually add human action effects (using arrows signed by square icons on top) onto the diagram only after having identified and fixed all the natural relationships between quantities, to simulate and indicate the effects that human actions will eventually generate on the system.

Another symbol that you can see on the diagram and that looks like a cut visible on some relationships. It indicates that the correlation between the two quantities has no immediate effect but will take some time to propagate. For example there is no doubt that some positive correlation exist in between design defects and number of faults in a software module, but I want to indicate that an increasing number of design bad smells will not necessarily increase faults in the short run but for sure will increase it on the long period, specially if the software will be reused and extended. Why should you highlight this type of delay in the propagation of effects? Simply to "pin" a warning that say:
be careful, this relationship will look insignificant on short schedules but on the long run will be determinant!

There is a last detail that I should explain. You can see the arrows starting from "customer's expectations gap" and "usage costs". They don't point to "customer satisfaction" but converge on the arrow connecting "Faults" to "customer satisfaction"...what does it mean? It indicates a multiplicative effect, it is like if the three effects overlap one another, generating a final effect that is not just the sum of the contributes but higher. In this specific diagram I am trying to say that expectations gap, usage costs and faults all three contribute to customer satisfaction, but if they collapse together the total effect becomes dramatic and customer satisfaction drops down more rapidly than we would expect considering the three quantities as separate measures.

This type of diagramming are useful for the following reasons:
they force us to reason about measurable quantities and phenomenons, dramatically reducing the amount of vagueness in our reasoning;
they discribe the effects of phenomenons and components interactions in a way that can't be ambiguous because the connection symbols semantic is precise and effective, they disambiguate the cause-effect relationship, also between phenomenons that at a firste glance would (erroneously) look unrelated;
they let us simulate the effects of different types of human control actions (through the negative, positive and open choice action symbols) on the overall system.

If you want to learn more on this type of diagrams and at the same time read an impressive book... "Quality Software Management - System Thinking" by Gerald Weinberg is the book to go for.

To be continued...