Unfortunately I believe there is no crossing point even in 10 years.
If quick fix works it is most likely a proper fix, if it doesn’t work then you dig deeper. It is also case if feature to be fixed is even worth spending so much time.
A quick fix works now. It makes the next fix or change much harder because it just added a special case, or ignored an edge case that wasn't possible in the configuration at that time.
There is bunch of stuff that could be “fixed better” or “properly” if someone took a better look but also a lot of times it is just good enough and is not somehow magically impeding proper fix.
It is a false dichotomy in that in the Aristotelian sense of "X -> Y" means that absolutely, positively every X must with 100% probability lead to Y, it is absolutely true that "This is a quick fix -> This not the best fix" is false. Sometimes the quick fix is correct. A quick example: I'm doing some math of some sort and literally typed minus instead of plus. The quick fix to change minus to plus is reasonable.
(If you're wondering about testing, well, let's say I wrote unit tests to assert the wrong code. I've written plenty of unit tests that turn out to be asserting the wrong thing. So the quick fix may involve fixing those too.)
It is true in the sense that if you plot the quickness of the fix versus the correctness of the fix, you're not going to get a perfectly uniformly random two dimensional graph that would indicate they are uncorrelated. You'll get some sort of Pareto-optimal[1] front that will develop, becoming more pronounced as the problem and minimum size fix become larger (and they can get pretty large in programming). It'll be a bit loose, you'll get occasional outliers where you have otherwise fantastic code that just happened to have this tiny screw loose that caused a lot of problems everywhere and one quick fix can fix a lot of issues at once; I think a lot of us will see those once or twice a decade or so, but for the most part, there will develop a definite trend that once you eliminate all the fixes that are neither terribly fast nor terribly good for the long term, there will develop a fairly normal "looks like 1/x" curve of tradeoffs between speed and long-term value.
This is a very common pattern across many combinations of X and Y that don't literally, 100% oppose each other, but in the real world, with many complicated interrelated factors interacting with each other and many different distributions of effort and value interacting, do contradict each other... but only if you are actually on the Pareto frontier! For practical purposes in this case I think we usually are, at least relative to the local developers fixing the bug; nobody deliberately sets out to make a fix that is visibly obviously harder than it needs to be and less long-term valuable than it needs to be.
My favorite "false dichotomy" that arises is the supposed contradiction between security and usability. It's true they oppose each other... but only if your program is already roughly optimally usable and secure on the Pareto frontier and now you really can't improve one without diminishing the other. Most programs aren't actually there, and thus there are both usability and security improvements that can be made without affecting the other.
I'm posting this because this is one of those things that sounds really academic and abstruse and irrelevant, but if you learn to see it, becomes very practical and powerful for your own engineering.
Well I mostly work on systems that people don’t have their lives on line and don’t care that much like HN or Facebook. If I cannot post my comment I can go on with my life.
Sometimes I get “hey you did too quick requests” while posting.
Proper fix would be making better check if I am really a bot or I just casted a vote and wrote quick comment - but no one is going to care enough.
If quick fix works it is most likely a proper fix, if it doesn’t work then you dig deeper. It is also case if feature to be fixed is even worth spending so much time.