True enough, in university I quickly learned to get things right the first time - because I won't have time for a second try. It's a habit I've kept after I graduated.

I think the parallel to software is pretty obvious. It's easy to say "I'll rewrite this later", but when later rolls around, you have 3 other deadlines to meet. Throw-away code might still stay in the production code for 2 years. Refactoring parts of the code is good and necessary, but there are only so many resources you can dedicate to it.

I guess if you're seriously considering rewriting something from scratch, you're already caught between a rock and a hard place. Rewrite, and you miss an entire development cycle at least - time that could be spent enhancing or adding features. Stick with what you have, and you have to work with a codebase that makes development a nightmare (otherwise you wouldn't consider rewriting).

Better to avoid it if possible - do a bit of planning upfront, refactor when you can, have enough tests that refactoring is safe.

At my last job we rewrote a large part of the application - but it was done piecemeal, over two years, and never halted development or delayed new features. Refactoring was "snuck in" as part of deliverables whenever it was possible and safe. It was worth it because the new code performed up to 2 orders of magnitude better, and was much easier to work with - but we never would've been able to do it if we simply decided to drop everything and announce that we're rewriting the app from scratch.