How do people get emotionally attached to software?
I mean positively emotionally attached to the point of plastering stickers on their laptop, or negatively attached to the level of raising their voices in discussions.
Here I explore a few causes that I have seen.
1. Attachment to strict teachers
This cause of attachment is common with compilers (Rust, Stan) and program provers. They nitpick and force you into a lane. After significant investment and boxing your problem into the right shape, they are given the green light like a priest giving you a blessing. You are now a member.
The harsher the teacher, the more rigorous the trial, the more attached is the feeling of belonging to an elite club of survivors.
2. Attachment to what you have spent building
Just spending a lot of time building something causes you to be attached to it. Firstly, design decisions can be personal expressions. Secondly, after spending many long nights or even months working on it, there is a sunken cost. It’s hard to consider that you have “wasted” your time. If someone tells you, “why don’t you use tool Y”, you’d laugh it off, not even trying to learn tool Y because you understand your imperfect work of love.
A more open minded point of view is to think of the “sunken cost” as an investment to deeply understand the challenges in that domain. Even if the developer drops the tool and switches over to something else, they now know the concepts and challenges deeply, at an expert level.
Unconvincing value propositions
Building new software is fun! Because of the two points above, the author is likely to proselytize around, trying to convert people to their great tool.
The expressed value propositions can harbor a communication mismatch: The inside view of the developer is not the outsider view. Their values of “it is well understood” and “easy to change” do not translate to the next person who has not edited the software yet. Likely, the outsider has also seen a few people proselytize, and then the difference in value may be difficult to see.
Work without impact to science
Every week there are papers on arXiv where someone invested months of work on a new data analysis technique and finally finds that it does not outperform the classic benchmark.
Sometimes this is stated outright. I think it is great science to try something new. But there are other cases.
Sometimes the benchmark is a setting unlike how the analysis will be applied in the future (for example: complete data, spectroscopic redshifts, known noise), or the benchmark statistic is non-standard to the field. In any case, whether the new technique is better or worse, the abstract invariable ends with “And therefore, our technique is a promising platform for future data sets.”
It is disheartening to think of the many person months wasted, because people did not think longer about what they should optimize for.
Personal reflection
I think I also suffer from some sunken cost w.r.t. nested sampling. It is quite addictive for me to think about algorithm variations.
That “no one uses my software” is not a problem I have though. What keeps me grounded is seeing a clear need in conference and hallway dialogs, combined with critical thinking to crystallize out what the core question is.
Leave a Reply