Have you ever, during your career, been forced to use Fear Driven Development, and how did you react to it and handle it ? By Fear Driven Development, I mean a scenario where your boss comes to you and quite literally says "get the project out by [some date in the near future] or you (and possibly the company) are done". I've found that I'm placed in such a situation not infrequently, and I have to break a number of my principles and practices when it comes to good software development in order to get the job done in these cases. It also kills me that I also don't have the time to come back and do things right, up until a point where we run into a problem and I'm forced to come back and change what I didn't want to do incorrectly (or inadequately) in the first place.
Yes, when I worked for a very small company (2 main developers, including me), every problem was a catastrophic one. I was lucky, though, since my boss was fairly technical and he was happy to let me, on occasion, to go back and fix up code that was written very quickly just to "get it done".
I remember one time we had a database crash and we had trouble restoring backups. There was the very real possibility that if the backups could not be restored that we'd lose a significant number of clients and basically put the company out of business. I was up until 4am that day in the data centre with my boss trying to get it back up & running. Let me tell you, the human body is not designed to be in that sort of extremely dry, highly air-conditioned environment for 10 straight hours!
IMHO, There's a difference between pressure-driven-development versus fear-driven-development. To me, any mission-critical system should be developed in a fear-driven way, though that should encourage more care and better testing rather than shortcuts.
Pressure is another story. The perfectly designed and or tested system is not feasible in some domains. Especially domains that involve clients with shifting demands. In many cases, clients just want "good enough" and are willing to handle the consequences.
I think that an engineer's job is to be able to know what corners can be cut with the relatively lowest impact, and to design in the first place to allow these corners to be cut. It is the role of the manager to understand the tradeoffs and try and mitigate them.
Unfortunately, some managers drive employees towards this sort of behavior for no good reason.
Unfortunatly, fear driven development (good term for this) is very common. The worst part is that you, not your boss usually has to pay the price when the bad code doesn't work later. If this happens over and over it might be time to look for another position.