For the love of Knuth, stop using Quality as one of your project axes!
Quality is non-negotiable - as soon as quality slips, everything else slips, too. Better options are Cost, Scope and Schedule (or Features, Price, Speed): http://en.wikipedia.org/wiki/Project_triangle
Not necessarily. Having code that is easier to modify or has fewer errors is a competitive advantage. Given that all your competitors are trying to improve their codebases, you should be trying to improve yours as well.
I don't think you understood my point. I agree with you up to a point. No programmer I have ever met has felt that any significant codebase they are working on is perfect. At some point you have to say that it's good enough and move onto new features or new projects.
I'd love to see that, but all too often it's the opposite - stuck on bugfixing antique, crappy code because somebody did a dodgy hack and figured it was "good enough". Taking the time to do it properly means that you ultimately go faster, not slower.
going faster doesn't matter if you're out of business. There is a point at which you have to say it's good enough. You can always make it better, unless you're arguing that all code you write is perfect. If not, then you agree with me, but want to repeat a talking point for some reason.
I agree that often people don't surpass the bar of "good enough". This is usually a result of bad programmers or bad employees, not a result of a company wanting to go too fast.
Going back to my original point, let me give you a real world example. I once worked at a startup doing a web app where there was an elaborate ajax heavy content entry process/forms. The javascript code for this page was an ugly hack, but it worked and was bug free as far as we could tell. The code could have been refactored but we decided not to because no other code on the site depended on this javascript code and it was highly unlikely that we'd need to change that page in the next year. We left it as it was and moved onto adding new features and that was the right choice. We never changed that code, and never needed to, but it wasn't great code. If we'd spent a week refactoring it then we'd have been late with some important feature that wasn't late because we decided to leave the js code as it was.
You're the one missing the point. Don't write the ugly hack in the first place, and you'll find that that code can be written faster, debugged much faster, and won't be an albatross in the long term. I also find that the crappier the code, the buggier it is and the more support requests are generated (the Pareto principle definitely applies here) - which sucks developer time away from more important things and compounds your problems.
This is something that I've seen several times, and in every case the people involved severely underestimated the time suck of crappy code. "It's not that bad" often means that the developer is spending 50% or more of their time working around deficiencies.
ugly hacks, assuming decent programmers, is usually a result of not knowing exactly what you are writing when you first start. This is common, and often it's not worth refactoring it as in the example I gave.
You ignored all the points in my last comment. Let me be more explicit. Bad code is only an albatross if you have to work with it again. What I'm arguing is that it's usually wiser to leave it as it is until the next time you have to work on it, then fix it. It's only an albatross if you don't fix it, and you only save time by fixing it if you actually have to touch the code again. So wait until you're certain that you're going to have to touch the code again, and fix it when you touch the code again, and not before that.
How often have you written a piece of code and known ahead of time that you'd never have to touch it again? Even throw-away code, like data migrations, often gets revisited several times while you're writing it.
So why is your supposedly decent programmer writing crappy code and assuming that they'll never have to touch it again?
Which is my original point. Traditionally the expectation is crappy-fast-and-cheap vs. perfect-slow-and-expensive, but that rarely holds. Instead it's usually the crappy code that ends up being slow to write and expensive, stuck in endless code and bugfix cycles trying to get it right.
I don't think quality and cheap are compatible. I can't envision a scenario whereby a project taking a long time will allow it to be done cheaply and well.
Find a good freelancer, offer him/her some interesting work with a deadline of "when you get around to it", and negotiate on price? I don't think this is impossible. (Of course, you'll need to find a freelancer who can do a good job but can't fill 100% of the hours (s)he wants to work. That may not be trivial, but it's possible.)
Doing it yourself over a long period of time as a personal project. That way you could do it as time permits, which is pretty much free, and then the code would also be up to your own standards because you did it yourself.
