If you're thinking "The what of software what?" then read on.
So the IKEA effect is a cognitive bias where users place a disproportionately high value on stuff they fully or partially made... which makes sense, one can and should be proud of the things they made... unless it's s**.
How does this translate into software engineering?
It's simple really, software developers AND clients too, often tend to invest time, energy, and money into their projects even though there would be other much better alternatives.
There are also multiple forms of the IKEA effect which I quickly list below:
Individual effect: It manifests in a way where an individual will devote more resources to get that extra work out of the "experience", be it coding or other tasks.
For example, a software developer will devote more of his energy to getting that extra work into a piece of code where a 3rd party plugin could have done the job better.
Group effect: This bias tends to spread among team members and companies too and it could manifest in multiple ways:
A team could be biased toward creating everything in-house just to have complete control over the whole development process (which of course is a falsehood) wasting valuable resources in the process.
Also, a company could charge more for its product or service to offer that "DIY experience" for its end-users. This is actually what IKEA is doing, hence the name of this bias.
We could also take a look at how this bias unfolds from a client's perspective.
The sunk-cost fallacy: Where a client devotes more and more financial resources into their project, where a rewrite of the code-base (which often is a smaller effort to do) would have taken a less financial burden from the start.
This is also happening because of a flawed view that a rewrite would result in resources lost, but in fact, oftentimes the opposite is true.
A refactor of a code base doesn't necessarily mean starting from zero, especially in regards to know-how. Given that the same team is assigned the task of a rewrite, they already know where the pain points are in the project, hence the refactor.
Control over the project: Where a client wants to keep control of every aspect of the project and the development process because of the false image that this creates.
"Not invented here" (NIH)... when the client refuses to use 3rd party modules in the project out of fear of security exploits, poorly vetted code, and the lack of control over it.
How to avoid falling into this trap?
First, just acknowledge that this effect exists and it's real and it will manifest in every individual. Be aware of the IKEA effect and always ask yourself: Am I choosing this solution because I invested work in it and it's made by me or is it something else?
Work from the outside in. When you're faced with a problem, explore it, and put in the effort of finding a solution, but don't just jump in head first into solving the problem. Create prototypes of code or tests to validate your idea before actually committing to it. This is also true with teams and this is why an MVP of a project could be very valuable early on in the development phase.
Prototype, validate, measure, rinse and repeat. Always.
Cover image copyright (obviously): https://commons.wikimedia.org/wiki/File:Ikea-logo.png