I've been very fortunate to work with and learn from some great mentors. In college, I had a professor who was very big on style and design and things like that. Your solution could have been technically perfect, but if it was poorly commented and/or organized, you were getting a C (at best). More recently, I've worked with guys like Rajiv and Faisal who put quality first and foremost - and emphasize not just the functional code but the rest of the supporting cast that constitutes the technical solution.
I think in code, and as a result I tend to rely heavily on refactoring. I like to have a general sketch in my mind of where I want the solution to head, and I gradually whittle my way there. I am also a big proponent of generic solutions to problems, and unfortunately, even when considering this upfront, requirements usually change. As long as you write well-abstracted, loosely coupled code, and you don't get too attached to the code you write, this approach can work very well.
The problem, though, is that in a team such an approach doesn't always work in practice - even if the team is small. When code works, it's all too easy to just leave it be, especially when you didn't write it and you're working under tight deadlines.
So I've changed my theory on things like this now. As soon as you allow yourself to take a shortcut, you are setting a dangerous precedent to yourself and to your colleagues that shortcuts are acceptable, at least in some scenarios. And once the precedent is set, it's easy to rationalize taking the next shortcut.
That's how you get erosion of quality over time - a lot of small compromises. The next thing you know, you have a shoddy foundation that you'll constantly build out on, which only compounds the problem.
For those of you who have played a sport in the past, you've probably heard the same rhetoric from your coach with regard to quitting or giving up in the face of adversity. The first time is always the hardest, but it's a lot easier to do again once you've done it without catastrophic consequences.
Now, don't misunderstand what I'm saying - I'm not against making compromises, I'm just saying it's important to understand that you should carefully consider each one and the potential consequences.