Wednesday, July 12, 2006 

Self-fulfilling expectations

A reader reminded me via email that I've been using the expression "self-fulfilling expectation" twice when answering comments from the agile crowd (see the recent post on TDD and an older post on project management) without ever really explaining what I meant.
A self-fulfilling expectation (also, self-fulfilling prophecy) is a belief that, when held [by enough people, in some cases] works to make itself true. A popular example comes from finance: for some unjustified reasons, a number of people start to believe that a traded company has financial troubles; they start to sell stocks, the company value begins to drop, they sell at even lower prices, and so on; in the end, the company may experience real financial troubles. For a variation, see the wikipedia.

What has this to do with software engineering? Well, quite a lot. I'll give an example, using non-code artifacts, say diagrams. Of course, it's just one among many possible examples.

Some people start with an initial belief that diagrams are a useful way to reason about some problems (if they're naive, they may think all problems, but let's skip that). They believe that having an abstract view of the code (without all the details of code) makes some reasoning simpler. They start to use diagrams, they hone their ability to create useful diagrams. They also keep diagrams alive as the project grows: not using reverse-engineering tools, because that would quickly make the diagram useless (full of details, basically a graphical view of code, not a model). Since they believe that diagrams must be abstract views, they make abstract models, so small changes to the code won't change the diagrams. Since they believe that some reasoning is simpler on diagrams than on code, when the change is so big as to impact the diagrams, they will first think on the diagram, find a good solution by playing with it, then implement the change in code. Anyway, the diagram will be kept alive, so at any time, they can switch the reasoning from code to diagram. Diagrams will probably prove to be also a good communication device. Naturally, there will be a cost (sometimes you won't even see an immediate value in keeping the diagrams alive) but in the end, the diagram will prove itself really useful, and they will more than pay back, just as expected

Some people believe that the only useful artifact (long-term) is code. They may sketch some diagrams in the beginning (or maybe not), but they won't keep them alive too long. As soon as they don't see immediate value on keeping the diagrams alive, they will scrap them. As they don't value diagrams too much, they won't invest much in making useful, long-lasting diagrams; in some cases, they won't even spend time learning something like UML in depth, learning maybe just the basic syntax. Therefore, they won't even be able to model much using diagrams (which immediately makes them useless, already fulfilling the expectation). Given the cursory knowledge of the notation, it will be hard for a group of such people to use diagrams as an effective communication tool (again, making it pretty useless, and fulfilling the expectation). If diagrams are not entirely disposed, they will soon get totally out of synch with code (since even large changes are done directly on code, not thought on diagrams). Therefore, they will give less and less value to the project, finally becoming useless, just as expected.

Note that you can't just say stuff like "use diagrams until they add value", because that implies that as soon as you don't see a short-term value you'll scrap them. In two weeks (or 2 months) they could prove exceptionally useful, if you keep them alive (prophecy 1). Of course, they won't be if you don't (prophecy 2).

The fact is, what we believe tends to get true. We come at points where an option is logical only within a belief system, and acting according to our beliefs makes those beliefs true. More on beliefs and values in Software Engineering another time :-)

This is one more reason why I don't like fanatism of any kind. Fanatics tend to close themselves in self-fulfilling, self-feeding belief systems, and lose the ability to see beyond that. My simple recipe? Keep your beliefs flexible - it's science and technology, not religion. Understand that there is not a single perfect approach to any problem, although we can try to find a specific almost-perfect approach to any specific problem. Finally, if you really have to believe in something, believe in what you would like to get true :-).

Labels: , ,

Quelli che dicono che il mondo non cambierà e che le cose andranno sempre male contribuiscono a fare in modo che sia proprio così.

Il mondo è come noi lo facciamo.

Fare le cose bene o male spesso ci si mette lo stesso tempo. Quindi conviene farle bene.

Progettare software, tutto sommato, è fare un pezzo di mondo.
Sottoscrivo :-).
but you are the extremist about "how not to be an extremist"?
[I appreciate the nerdy need to play with concepts and categories :-))). Still, here are a few notes for anybody that could take your words seriously (if any :-)))]
As I pointed out in other posts, there are things that can't be properly defined, and surely not analytically defined. If you try to, you end up with a misrepresentation.
So, true agility can't be defined, or it won't be agile anymore. "The Tao that can be seen is not the true Tao" :-). And so on.
Surely, by speaking against fundamentalism, one may look a little fundamentalist (especially when someone doesn't like what you say :-))).
As usual, appearance and substance are quite different things. As I don't want to write my own apology :-)), I won't even try to explain why I'm not what you said. That's the dreaded exercise for the reader :-)).
Surely, by speaking against fundamentalism, one may look a little fundamentalist (especially when someone doesn't like what you say :-))).

Great! This way I can defend myself quoting you: "By speaking against FUD on Agile, one may look a little fundamentalist (or zealot) especially when someone doesn't like what you say"

Thanks Carlo ;-)
Marco, of course :-)) when you speak about FUD (on agile, or whatever) you're NOT talking about me, are you?
Carlo: no, not about you. Not in this universe :-)
Post a Comment

<< Home