A little discussion between myself and a peer which I thought others could provide a bit of insight towards. (The peer develops in Java, not Perl, but I doubt that language factors into this.)
Having a short discussion about how to best provide the user with a certain type of functionality which we've tried to provide in the past, although not entirely successfully. I say not successfully as we've had multiple "critical"-level issues with it. My coworker thought we had solved all the problems, I wasn't comfortable with that. And then, today, I find that another teammate had (just last week) found yet another problem with this functionality that, admittedly, had been there since the beginning, just waiting for someone to find it.
This is when I said of my design (a radical departure from past functionality):
All I'm trying to do is make it impossible to have bugs. Well, these types of bugs. Quality isn't about fixing bugs, it's about preventing them. It's not about fixing the edge cases. It's about having no edge cases.It was about this point in the conversation that he started to become convinced of why I wanted to disrupt the existing functionality from the core to completely change the way we looked at the problem.
Then I realised that this was quite concise, and thought it rather catchy. It got me wondering if there were any concise, potentially catchy phrases that can prove useful in aligning everyone's thoughts around the core ideas of producing quality output. This may have nothing to do with producing idiomatic code, or clean code (although I would think that clean, idiomatic code is much more likely to be of high quality). This may be just quality of design, which doesn't even allow for code problems because the design is so thoroughly bullet proof.
PS: he writes Java, I write Perl, and we're both talking about the C++ code ;-) As I said, this is a language-agnostic observation.