Hello! Nat here, with the latest news from StoryTime. If you’re reading this, you signed up to get monthly updates about our development process.

If you’re reading this, you can take a look at StoryTime right now, by logging in with

(Keep in mind that any backlog you create with those credentials will be visible to everyone else with access to the application.)

This is officially the 12th update, which means… we’ve been doing this publicly for a whole year now!

I have two pieces of news for ya’ll this month.

Do YOU want to be a founding customer?

If you’re reading this e-mail, you’re making it possible for us to continue doing this work. Thank you.

If you’d like to support us even more, we now have a paid offering! We’re looking for 5-7 founding customers — if you’re ready to start using StoryTime “in anger,” send us an e-mail.

Oh boy! Distributed Linked Lists!

The main thing we got done this week was finally thoroughly debugging, fixing, and cleaning up after a nasty bug where rapidly moving stories, especially between stacks, and especially if you were in Australia, could cause stories to disappear, or the entire backlog to crash.

It took a while to figure out what was happening thanks to a classic debugging foible: I was looking at the pattern of events in the database and said to myself, “That sure looks like a transaction isolation failure. Two move_story operations are reading the same data and building change sets, and then applying those change sets without one failing, because it’s committing data that was altered by another transaction. But surely that can’t be what’s happening.”

This was technically correct! The best kind of correct!

It turns out that if you (1) have complex business logic about what makes a database state “valid” (2) check that all transactions conform to those requirements before exiting them but (3) don’t actually roll back if those checks fail you will end up with behavior that looks a lot like write skew.

But because I was sure that the issue couldn’t possibly be interleaved transactions, I spent a lot of time trying to precisely replicate the exact sequence of operations that replicated the error without any interleaved transactions, rather than just looking at what the error reports and my tests very clearly empirically demonstrated: The problem only happened when move_story operations occurred simultaneously.

It also took an embarrassingly long time to write the code to fix some of the corrupted backlogs this issue left behind. I finally cracked it through a combination of (1) pairing with Jesse and (2) drawing diagrams. In an office this all would probably have taken me a couple of days, because I would have already been pairing, and because as soon as I got confused I would have gotten up to start drawing on a whiteboard.

Do I regret implementing order in StoryTime backlogs as a linked list? Sort of. Will we someday change to float-based position? Maybe. I do like that the linked list approach makes it very clear when a story has been moved to the wrong location, especially when moving stories between stacks. It’s definitely something I’ll take another look at in the future but for now I have spent quite enough time writing code that doesn’t actually change the apparent behavior of the application, thank you very much.

Looking ahead.

Next up, we’re focusing on measuring performance and general zippiness. We’re looking for opportunities to refine the existing app while talking to lots of potential customers. If that’s you, reply to this email! We want to talk with you.

Happy New Year