I find it very strange that most of the comments are about how this is okay. I don't think it is, because it prevents software evolution and impedes maintenance. My comment mostly goes to the "hacky" way of implementing something rather than a missing feature/missed performance target. That may indeed never come - though if you have a classic N+1 select problem that is fine now, it's probably good to tag it in the comments, you'd be surprised how quickly it will come.
However I have been burned a number of times by a so-called "quick fix" that looks like a bad idea in code review and then later prevents the evolution of the system in some way. Code that is "hacky" usually leaks abstractions, doesn't compose with anything else and only benefits the author at the time it's written as a "quick win". Plus the original author knew enough to call it a "hack" but did not explain why they could not do it properly - a person that consistently does this is not a person you can trust on your team.
It is probably up for debate what the balance is (think time value of money but for technical debt), but in the industry it is clearly the wrong side of the scale, and this is a major drag on productivity.
However I have been burned a number of times by a so-called "quick fix" that looks like a bad idea in code review and then later prevents the evolution of the system in some way. Code that is "hacky" usually leaks abstractions, doesn't compose with anything else and only benefits the author at the time it's written as a "quick win". Plus the original author knew enough to call it a "hack" but did not explain why they could not do it properly - a person that consistently does this is not a person you can trust on your team.
It is probably up for debate what the balance is (think time value of money but for technical debt), but in the industry it is clearly the wrong side of the scale, and this is a major drag on productivity.