Persistence to me extends the reality principle to even minor and potential issues: they *must* be addressed (the "almost predatory" response) - driving engagement.
Obstinance to me reduces the reality principle to consistent facts, and serves more as avoidance.
(The flaw of the Quality perspective stems more from expanding bureaucratic incentives and achieving scale through excessive punishment driving aversive behaviors.)
A bit less than a year out of college I found a pretty significant bug in the compiler (I forget the bug! I do remember the one major bug I let slip out into a release though) well after everything had been signed off on. I brought it up in the team meeting and the principle dev asked me directly "Do you think we should cancel the release to fix this bug?" I wasn't sure of myself and he told me that "it's your call", and I said that yeah, we should fix the bug.
For anyone under 35 who is confused by this, was before releases were rolling and shipped online. When Microsoft released a major version back then, it had a (IIRC) ~10 year support contract attached to it (and if you found a bug and were on a good enough of a support contract, the dev team would develop a custom patch for you to fix a bug in a 9 year 6 month old release!), and a lot of gears were set in motion to make a release happen.
This was the norm at Microsoft for a long time. I was originally attracted to the SDET role because they were the last defender of the customer experience, they were the engineers who held the line on quality. The entire industry is worse off for the SDET role having been eliminated across all major software companies.
Make one small 1 degree mistake on a rocket launch, you will end up hundreds of miles off target.
Make a small mistake in an organic system and you'll be fine, you can just iterate. You'll drive yourself crazy trying to get it perfect.
The trick is knowing which situation is which.
Or sell small amounts at a crazy margin. Getting rich is about profits not about sheer revenue.
I'm not sure that it was, in the aggregate, the most beneficial decision for the company, but it was the decision they made, and I had to go along with it.
I do think that we could have addressed the Quality issues, in a couple of months, and the app was something that I think would have been "revolutionary." That "revolutionary" part probably contributed to its demise. Many QA types are very conservative, and risk-averse. I suspect that they wanted to find problems, because they didn't want to deal with a very different (albeit awesome) kind of application. There were also a couple of other reasons, which I won't go into, here, but they weren't particularly well-handled. They did make it easier for the conservatives to sway upper management.
My experience, is that folks can't deal with "it depends." We have to have "hard and fast" rules, to be applied in all contexts.
Determining "it depends" almost always requires scars and contusions. Less-experienced folks often have a much more difficult time, making these decisions, than folks that have been around the track a few times.
The folks that decided to cancel that project were very highly-placed executives. It wasn't an easy decision. However, one of my mistakes, was underestimating just how obstinate and change-averse, the QA people could be, and how much real power they wielded. If I had accepted this, I maybe could have saved the project. It was a hard lesson, but one I learned well.
That corporation made some serious mistakes, mainly from being so risk-averse, that they allowed their competitors to eat their lunch, and suffered a pretty big implosion. I suspect that they will do OK, in the long run, but they took a real beating. Ironically, the reason they survived that drubbing, was because of their fiscal conservatism.
"Good judgment comes from experience. Experience comes from bad judgment."
If you want to see "stubborn," look no further than their QA Division. In the US, there used to be a running joke, that if you had "Quality" in your job title, it meant your career was dead. At this company, it meant that you were headed for Executive Row. Many VPs and General Managers (a very powerful title, at this company), were former QA people.
And, boy, were they a pain to deal with. They would have 3,000-line Excel spreadsheets, and if even one of those lines was a red "X", the entire product line could get derailed. I had a project that we worked on, for 18 months, get nuked at the last minute, because they didn't like the Quality. I worked with an SV startup, that had a project canned, for pretty much exactly the same reason. The startup folks didn't seem to take the Quality seriously, which was basically a death sentence.
In that company, the kind of "stubborn" the QA people demonstrated, would be considered absolutely essential. I know that most folks around here, would not put up with it for a second.
They wouldn't be wrong. Making superb-Quality stuff is not a big moneymaker. You want lots of money, make lots of cheap, crappy things, and sell them at a small margin. The market is a lot bigger, and most people have much higher tolerance for crap than this company's customers.
As is the case with almost anything in life, "it depends." There's really no one-size-fits-all, "magic elixir." Every end may be reached by a different path.