Best Practices are Not the stop of inovation, they can be the spur to it. Many times, I will write something "quick and dirty" to make sure my concept works, then I re-write, as many times as I need to, to make sure someone else, can add to or update my code as the need arises.
You want to be innovative, then figure out how to do it, then re-write to make it work with best practices. I would not mind hiring a "quick fix artist" IF, I could also see the cleaned up code.
"Dirty code" and "Quick Fix" MIGHT get you out of an issue, however if not cleaned up and made "Best Practice" i.e. clean code with explanations, you will not find others willing to work with you or support your efforts.
We have all add to through a "patch" into code to keep it running, (Even Microsoft) But don't plan on the patch to fix sloppy work. If you know it will be needed, do it now.
you will not find others willing to work with you or support your efforts.
Quite a presumption on your part.
Reality: Others want to know "how did you do that ? !". Deliberately exaggerating, I look at so-called "best practices" as a combination of someone with influence trying to make me into a follower (of them) rather than a leader - and (other part of the combination) a fad for coding like the latest in overpriced fancy sneakers. One needs simply to be open to new methods to solve what (in reality) are old problems.
Real "best practices" is the most appropriate solution for a problem - in any field - crossing all boundaries. And - since I follow logic and efficiency I keep my audience attentive and appreciative with . . . . . . . extensibility* and comments.
Battles are not won by those who read the books - they're won by those who write them.
Paraphrasing that wine commercial, "I will release no code before its time".
Sidetracking a little: We used to end the Saturday shopping round at our local microbrewery pub. Once when I ordered a glass of porter, the waitress checked her watch: I'm sorry, but the brewmaster will not release the new batch of porter until 3 o'clock...
...but users do care if the app performs well, if it doesn't produce unexpected errors, doesn't crash, produce expected results overall and if it's pleasant to use, has good UI. And all of this can be part of doing it well.
So what you're saying is that the user experience is what matters most, but the business rules must be taken into account. And given that this is VERY subjective, can we really get by with just "getting it done"?
Cobalt Software Systems, LLC
When Quality Counts...
The heart of a developer wants to do it "right"... perfect... in most cases.
Exceptions are when you get forced to write stuff you really hate... and you just want to get it off your desk.
But in normal circumstances, you want to get it done and you want it to be pretty... stable... and as-perfect-as-possible.
Many of todays paradigms try everything to work against this. scrum/agile tells you to deliver fast and refactor often. that's fine from a money-perspective. I personally love much of the agile things, but it more often than not hinders me to do things perfect.
sometimes it feels more like a prototype that will "get fixed later". as long as the story points are met, everything is fine.
To my luck I am part of a team that sees exceeding the estimated story points less a factor than delivering something that might not hold to the customer's expectations. But there are other companies out there that act blindly.