If you find a correctness bug in Dolt, we'll fix it in 24 hours or less. We even wrote a blog about how we do it. The blog did well on HackerNews, generated some internal discussion, and now I have an addendum.

The nature of Dolt as a version-controlled, shareable database and DoltHub as an internet accessible place to share Dolt databases makes it much easier to get reproducible issues from customers. Also, DoltHub developers don't hate the pledge. Let me explain.

How'd we Get Here?

My previous 24-hour pledge blog did well on HackerNews. We didn't even post it. It just ended up on there somehow.

Some of the feedback was about how toxic the developer pledge must be to our development culture. This obviously drove some discussion on our internal Discord. We're all kind of proud of the pledge which I'll explain later. So, there were some jokes and me opining about hustle.

Then Max drops this gem.

I totally forgot to talk about Dolt's version control features aiding our debugging efforts, helping to ensure we can fix bugs in 24 hours or less.

Version Control Helps Debugging

We all know this already. That's why code is version controlled. Dolt is the world's first version controlled SQL database. That must help debugging but how?

Data Sharing

Dolt is a database built for sharing. DoltHub is an internet-accessible place to share Dolt databases. When a customer has an issue, we often ask, "Is your database private?". If it's not, we ask the customer to push the database to DoltHub where we can clone the exact state of the database at the time of the bug. The bug is often reproducible at this point in a few SQL queries. At that point, attaching a debugger if necessary to pinpoint the bug in code is easy.

Even if the database is private, we can set up a private DoltHub database to collaborate on. DoltHub supports private databases much like private repositories on GitHub.

We often talk about how this capability can be used in your own deployment of Dolt. Found a bug in your data in production? Clone the databases to your laptop and debug without fear of breaking anything.

History Available

Moreover, Dolt has all the history of what changed going back to the inception of the database stored in it. When we're debugging, we can see what changed and how. This capability often helps when debugging source code and it helps debugging database bugs as well.

Case in Point

So, a few minutes after this discussion, it happened! We asked a customer experiencing a bug to share their database with us.

And yes, we fixed their issue in under 24 hours!

Description: dolt conflicts cat fails for really long conflicts
Bug: https://github.com/dolthub/dolt/issues/7774
Fix: https://github.com/dolthub/dolt/pull/7877
Release: https://github.com/dolthub/dolt/releases/tag/v1.38.1
Elapsed time: ~6 hours

Your devs must hate you...

The big scuttlebutt on HackerNews was about how the 24-hour bug fix guarantee must create a toxic work environment. Here at DoltHub, it's quite the opposite. We're proud that we can fix bugs quickly.

The 24-hour bug fix guarantee grew organically out of us prioritizing and fixing customers bugs fast without any sort of guarantee or internal pressure. Jason just got in the habit of prioritizing customer issues and fixing them fast. Once we saw that we could fix bugs fast, it became an internal challenge to fix bugs in less than a day, with everyone striving to beat the clock. Finally, after a couple of quarters and a couple of dedicated bug fixers being able to pull it off, Jason and then James, we started communicating it externally as a promise.

I can see how at other companies the bug fix guarantee could be used a cudgel to make developers work long hours or off hours. Certainly, I've been at Amazon when developer on-call was used in this way. That's just not the case here at DoltHub. We might usher a bug through testing in the evening but systemic off hours work is definitely not a thing.

If you know James, "not really" is about as passionate a response as you're going to get.

I think the truth is, the developers at DoltHub are proud of what we built. We willed a new, novel SQL database into existence from left for dead parts. Most of us have been working on this for a long time and we're excited it isn't broken most of the time. We're happy to fix bugs you find as fast as we can.

And since our product helps with repros, our tooling is good, we have a lot of tests, and the bugs get priority, we can fix bugs in less than 24 hours most of the time. So, it doesn't hurt to let you all know we can.

Conclusion

Care to test us? We'll fix your Dolt bug in 24 hours or less. Please cut an issue. Want to talk about Dolt's promise and how we achieve it? Come by our Discord and we're happy to discuss.