The Ikea Effect and Software Development
In his book The Upside of Irrationality, behavioral economist Dan Ariely discusses a cognitive bias known as "The Ikea Effect." Stated roughly:
We ascribe more affection (and hence more value) to things that we have labored over.
Named after the popularity of Ikea's assemble-it-yourself furniture, the idea is that when we work to produce something, we treat that product as something more valuable than it actually is (or than others would treat it). Ariely finds evidence of this phenomenon in tasks ranging from building cars to baking cakes to following a simple set of instructions for making an oragami frog.
As with many cognitive biases, this one haunts software developers. We develop certain emotional attachments to the code we create, and this leads us to value our own software as inherently better (or inherently more valuable) than its competitors.
This has both advantages and disadvantages.
On the up side, this attachment instills in us a desire to maintain and care for our software. We view its improvement as an investment, increasing the value of something already quite valuable. And we take care of it because we have a certain affection for it that extends, perhaps, beyond what is objectively warranted. Because of this attachment, we do in fact build better software. Not necessarily because we started with something phenomenal, but because we are willing to invest more. And through iteration our software really becomes better.
But on the downside, our devotion to software we have created can become a form of dogmatism. If we become overly attached to what we have created, be become a harsh critic of competitors, or we become miopic and unable to learn from other software. Or worse, we become so protective of our software that we actually stymie its growth by refusing to change things. "It's already perfect as it is."
In some cases, I've seen contributors to open source projects fall prey to these downsides. Becoming fierce advocates, zealots even, about the software they created or helped create, they become unwilling to make critical changes because the thought of changing "what is" to something unknown seems to devalue the software as well as their investment in it. And sometimes communities are torn apart when competing reactions to the Ikea Effect come into conflict: One wants to change and improve, to care for, while another wants to keep it the same because it's already great. Tragically such a bias can lead community-killing schisms.
