Sunday, January 22, 2006 

Functional Fixedness and Einstellung

A few days ago, while teaching Object Oriented Design, I introduced the idea of initiative as defined by Andrew Koenig in "Turning an interface inside out", Journal of Object Oriented Programming, May 1997.
Koenig shows how turning an algorithm into an iterator can make it more reusable and even more efficient in several cases.
The idea is pretty simple in retrospective, but requires a break from traditional thinking. We usually implement an algorithm as a function; we are actually "trained" to do so.
In Gestalt Psychology, this is known to cause an Einstellung effect, whereby after repetitive training we tend to [automatically] use the same approach to problem solving, even though better approaches could be [easily] found for specific problems.
A similar (although distinct) effect is that of Functional Fixedness: in several experiments, human subjects didn't see an opportunity to reuse some artifact with a different function, if a primary function was suggested in the problem setting. For instance, a box that is provided full of objects (therefore suggesting a containment function) is frequently not reused with a different purpose, while an empty box is more frequently reused.
Functional Fixedness appears in programming too, as we seldom reuse language constructs for different functions. Template Metaprogramming in C++ is a great example of what we could get by breaking away from functional fixedness (in this case, templates are used to do compile-time calculations, instead of "simply" providing a way to create type safe algorithms and containers).
It would be fun to list down common concepts in modern programming languages (types, functions, etc.), their "primary function" (structuring, computation, etc.) and then look for any chance of creatively reusing language constructs (like: using a delegate for structuring or storage, etc.). Maybe another useful technique like template metaprogramming is sitting there, and we just need to look from the right perspective :-).
For those of us involved in requirements analysis and software design, the effects known in Gestalt Psychology as self-limitation and parasite implication are also quite interesting, but I'll save them for another time...
[I actually took a diversion while teaching, and talked about the stuff above for a few minutes; interestingly, nobody looked at me like I was crazy :-), or if they did, I didn't notice :-)].
Comments:
Nella mia ormai ventennale esperienza di programmatore mi è capitato spesso di dover risolvere, algoritmicamente parlando, problemi molto simili ed in molti casi proprio gli stessi problemi. In alcune occasioni ho riciclato alla grande il codice steso in precedenza, talvolta migrandolo da un linguaggio all'altro. Altre volte invece ho riscritto di sana pianta l'algoritmo risolutivo domandandomi se il gioco valeva la candela. Sembra la storia dell'acqua calda e a nessuno pare saggio reinventarla. Eppure a volte fare tabula rasa ci consente ti trovare soluzioni più brillanti, evitare insomma che cattive soluzioni si perpetuino all'infinito. Altre volte mi è capitato di verificare che le soluzioni precedenti, anche se ineleganti o sorpassate facevano comunque il lavoro più onestamente. A nessuno piace faticare gratis e quindi il riuso sembra la via più comoda anche se a lungo andare toglie il piacere dell'invenzione e magari l'innovazione viene mortificata. Quello che mi preme sottolineare è il fatto di avere un approccio critico su quanto facciamo. Possiamo anche permetterci il lusso di non adottare sempre le soluzioni immediatamente migliori: l'importante è la consapevolezza delle nostre scelte.
 
Post a Comment

<< Home