For context, I’ve been experimenting with a small open-source prototype while thinking about these ideas:
https://github.com/manux81/qddd
It’s very early and incomplete — mostly a way for me to explore what breaks once you actually try to model time and causality in a debugger.
That’s a very fair point.
The hardest bugs I’ve dealt with were almost always the least reproducible ones, which makes even very powerful debuggers hard to apply in practice.
It makes me wonder whether the real challenge is not just having time-travel, but deciding when and how much history to capture before you even know something went wrong.
This resonates a lot.
Framing debugging as an investigation — with hypotheses, evidence and gaps — feels much closer to how I experience real debugging, especially on complex systems.
What I’m still unsure about is how much of that investigative process tooling should make explicit, without overwhelming the developer or turning it into a full case-management workflow.
Yes, that’s a good example — thanks for the link.
Tools like this seem very strong at visualizing and exploring state, but they still tend to stay fairly close to the traditional “pause and inspect” model.
What I keep struggling with is understanding how a particular state came to be — especially with concurrency or events that happened much earlier.
That gap between state visualization and causality feels hard to bridge, and I’m not sure what the right abstraction should be yet.