You aren't the only one. I just recently realized the same pattern and posted the idea of "Debug Driven Development" to my LinkedIn. It was nice to find your article here from 2006. I contrasted the idea with Test Driven Development (which I never used), but I do like to do Debug Driven for complex code lately, mostly to see the program run in real time and keep my iterations tight. I find defects in data quickly and can just abort the program as soon as I see it's wrong. It works well for me, though I still have to go take a walk now and then when it comes to thinking up a different approach if the one I'm trying isn't working. I also get programmer's cramp sometimes, for various reasons. I also don't like a broken system at any point, although incomplete is fine. It being incomplete drives me forward, through the bugs and the tough challenges.

@Wren I couldn't have known it when I wrote the post (since it didn't exist!), but Rust's todo!() macro really captures what I wanted (with the old XXX exceptions). I'm surprisingly happy each time my code hits a todo!() because, often, it's very easy to fill in now that I have a concrete test case!

@Laurence That todo!() matches up to the TODO comments which get picked up by the various JetBrains and maybe other IDEs in other languages. After thinking about your use of being Debugging Driven, it occurred to me that I'm leaving breakpoints where I plan to do testing, and when I don't need them, I disable them before removing them completely. I also throw exceptions earlier, though they tend to stay in the program. So it's a bit different, yet all these things seem to be ways to clearly mark code in ways that will get attention. Maybe it's because letting things languish cause more anguish down the line.