(2024-01-10) Bjarnason Sunk Cost Fallacy Chasing A Halfbaked Idea For Much Too Long

Baldur Bjarnason: Sunk Cost Fallacy: chasing a half-baked idea for much too long. Colophon Cards: It all began well. In the first half of 2022 I worked, part-time, on a research project called Colophon Cards that was funded by The Icelandic Centre for Research’s Technology Development Fund.

*at the end I was left with a few different design prototypes I was relatively satisfied with.

I documented the research on the project site and on my blog, but I didn’t publish the design prototypes because I wasn’t sure what I was going to do with them next. So far, so good and it left me with an established, if minor, presence among note-taking enthusiasts*

the sensible thing would have been to continue the work in early 2023 with newsletter essays on knowledge management and note-taking as well as taking one of the design prototypes and turn it into a technical prototype to test the waters. But there was one wrinkle – or a crossroads of sorts.

A crossroads where I took the wrong turn.

I made a few mistakes with the project. The name was the first one. Nice as the name “Colophon Cards” is, it was tied a bit too strongly to a specific design metaphor.

The assumption that the project would inevitably target power users with every complex features you can think of was also misguided.

The basic design I ended up with instead prioritised findability and retrieval.

I would concentrate on a single use case for note-taking instead of all of them: memory aid.

The wrong turn came because I decided I had to solve the “offline problem”. Classic developer scope creep.

People generally expect their notes to be available immediately and that opening a note shouldn’t rely on a network connection. (Some people.)

Many people I interviewed talking about having tried out several apps over the years. The need to store your notes offline was, in part, a symptom of distrust.

This was a bad decision both in terms of UX design, software design, and just overall execution of the idea. It resulted in massive over-engineering and overthinking on my part.

Not in the least because there are too many ways of making “offline” work.

Synchronisation: This is probably the most straightforward approach to the problem

It’s not simple, but it is the simplest of the various local-first approaches.

CRDTs: Their downside is that they’re quite slow, memory intensive, and require substantial file space, relative to normal file editing. Existing CRDT libraries, such as Yjs are some of the most optimised pieces of JS code you’ll ever see and even that hasn’t been enough

Distributed version control: Related to CRDTs are distributed version control systems (DVCS) such as Git, Darcs, Mercurial, or Fossil.

The problem is that a bookmarking service doesn’t really need any of this. In fact, very few apps genuinely need any of this.

But I was convinced I could turn this into something meaningful, so I decided to come up with an app idea – a collaborative document editing service – and see if I could get funding to develop it further.

This was close to the opposite of what I should have done.

Of course, it kept getting rejected. But with each funding application I put more work into the idea and more thought in the system’s design and the more invested I became in it.

It’s pretty close to being a textbook case of the sunk cost fallacy, which means I can’t even say that I don’t know what I was thinking. I do know: “All this work I’ve done can’t have been a waste! I just have to do more work to get it going!”

These are not rational thoughts, and it took me much too long to see that.

So, what would the right move have been?

The first step would have been to continue to research the various problems people have with bookmarking, knowledge management, and similar tasks. If, in my research, I found somebody with a problem that I knew how to solve, I could have written a blog post or newsletter entry on how you would solve that problem.

It would also have made sense to write more about the issues with knowledge management and retrieval (i.e. note-taking) that specifically concern software developers.

In the longer term this might have led to a book.

Colophon Cards itself is tougher. Slowly building it into a Minimum Viable Product would have made sense, but building an audience on bookmarking and note-taking would have to have been a priority

Turning it into an open source project might have mitigated some of the risk or at least bought it some mindshare.

But, I didn’t do any of these things.

What should I do now?

Writing about knowledge management, note-taking, and bookmarking is still something I should do more of

Working towards a Colophon Cards MVP still makes sense, although it should be a relatively low priority task.

But, having made the mistake in the first place actually opens up some opportunities.

I now have skills purely because of my misguided dedication to a half-baked idea

Next: the mistake of involving myself in the AI Bubble.