I find myself pondering over this question from time to time, again and again. I want to do things the right way: to write clean, understandable and correct code that is easy to maintain. However, what I end up doing is writing patch upon a patch; just because there is no time, clients are waiting, a bug should be fixed overnight, the company is losing money on this problem, a manager is pressing hard etc., etc.I know perfectly well that in the long term I am wasting more time on these patches, but as this time spans months of work, nobody cares. Also, as one of my managers used to say: we don't know if there will be a long term if we don't fix it now.I am sure I am not the only one entrapped in these endless real/ideal choice cycles. So how do you, my fellow programmers, cope with this?UPDATE:Thank you all for this interesting discussion.It is sad that so many people have to choose daily between a quantity and a quality of their code. Still, surprisingly many, people think it is possible to win this battle, so thank you all for this encouragement. 
How do you balance between do it right and do it ASAP in your daily work?
project management;programming practices;management;workflows;software schedules
Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all these checks and balances, we suffer from the same problem you do.At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or demand change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen. All sorts of little things can culminate in a situation where we are forced into the conundrum of do it right or do it ASAP. Almost always, we are forced to do it ASAP.As software craftsmen, developers, programmers, people who code for a job -- it is our natural inclination to do it right. Do it ASAP is what happens when we work to survive, as most of us do. The balance is hard.I always start by approaching executive management (I am Director of Software Development and an active developer in that group) to defend the schedule, team and work being done. Usually at that point I'm told the customer has to have it now and it has to work. When I know there is no room for negotiation or give, I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customer's need to get it ASAP, but something will go and it will get pushed into another sprint. This is almost always OK.When you are unable to deliver because there are so many bugs, code quality is bad and getting worse, and timelines are getting shorter, then you are in a different situation than what I describe. In that case, current or past mismanagement, bad development practices that led to poor code quality, or other factors may be taking you on a death march.My opinion here is to do your best to defend good code and best practices to start pulling your company out of the trenches. If there isn't a single colleague willing to listen or go to bat for the group against management, then it might be time to start looking for a new job.In the end, real life trumps all. If you are working for a company that needs to sell what you are developing, then you will encounter this trade-off daily. Only by striving to achieve good development principles early on have I been successful at staying ahead of the code quality curve. The push and pull between developers and salesmen reminds me of a joke. What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying. Keep your chin up and try to do the right thing as you go.