In my experience, corporate bosses are not against good code per se. They merely think of everything in terms of cost/benefit analysis. If you can think like they do for five minutes every day (yes, I know, it's harder than profiling a serial killer sometimes) then you can present your boss with good arguments for good code.

For example, why factor out similar/identical code into subroutines? Because it's easier to understand and debug, plus future code is faster to write. It's in the company's best interest to have good code. Why do an analysis phase before a single keypress? Because it'll save you from having to rework everything at the last minute.

Good code is not always clever or artistic code. For me, good code is the easiest code to write and understand later.

Yes, bosses demand insane schedules. There are some ways of handling that. For example, check out IFPUG, the International Function Point User's Group (www.ifpug.org). Doing a function point count of a new feature request can be a good reality check for your boss, since it gives a fairly solid measure of the amount of effort required to get the new feature done. Coding the thing well or poorly won't get you done any faster, really... you need to implement the same features, and that simply takes a certain amount of time, no matter what the code quality. If you can inform your boss of that... okay, it won't make you any more popular, but at least you'll be accurate and consistent.

So it's really just a question of when you spend the time on the code: in the design phase, in the coding phase, or in the debugging phase. (Or in the lawsuit phase.)

stephen