Sometimes, it makes sense to do it quick and dirty. If you need a demo by Tuesday to get a foot in the door, or if you're not even sure what you are doing. Bang something together figure it out, write it properly later.
The cost of banging it out any old way that works is simply deferred. Later you pay the cost, either in a re-write or in maintenance nightmares.
If your "feature" has infected a lot of the rest of the code base, then a rewrite is expensive. If it's in structural code, which everyone depends on, then that nasty interface is already in use, and now, not only do you pay back the work you saved, you also pay back the interest and penalties. (You may have thought that credit cards were harsh). There's even a term for this :- Technical Debt
As you add hack after hack to a project, or even just messy code that's difficult to follow, the savings start to disappear. Now to change something, you need to spend more time understanding difficult code. Now it takes more time to change anything. The process continues until the code becomes intractable. Then each bug fix introduces new problems. Each change takes longer and longer.
People say they have no time for refactoring, automated testing, and just plain writing better code. I'd argue, you don't have time not to.
