Thanks for your reply and interest in my well-being! I would like to stress that this is based on my first experiences and most definitely not intended as some sort of recipe for how to do things. Hell - it's not even how I'd like to do things!
At the risk of turning this into a cathartic thread about individual's values, the point I was trying to make is that my own values have to be tempered by those applicable to the project, at least with respect to the things I valued highest as a lead developer (i.e., the team and the code). The implication is not that the software is now "low quality" but that it is now "good enough" - a metric (albeit a vague one) that needs to take into consideration the likelihood and cost of future decay. There is also no reason to believe that quality will drop over time; it will continue to be "good enough" although naturally subject to decay.
You're absolutely right that this pains the developer in me as I'm used to delivering the best of both worlds; high quality and on time. To ignore the cost of this type of approach to the client would be a bit irresponsible, though! There are cheaper ways to develop which may or may not be perfectly alright for the task. Perhaps you're right - "pragmatic" is far too lenient a word; "responsible" and "objective" might be better.
When constrained by such inconveniences as cost, the choice may well be between something good enough on time and something great later. Personally I'd definitely opt for the latter! But then I'm not the one who might lose first-mover advantage if the software's delivered later.
As for job satisfaction, there's less in some areas and more in others. Whether I'll like this new balance as much as cutting code I think only time will tell.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).