<p>Technical Debt <a href="http://www.martinfowler.com/bliki/TechnicalDebt.html" rel="noreferrer">via Martin Fowler</a>, <a href="http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx" rel="noreferrer">via Steve McConnell</a></p>

<p>YAGNI (You Ain't Gonna Need It) <a href="http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It" rel="noreferrer">via Wikipedia</a></p>

<p>BDUF (Big Design Up Front) <a href="http://en.wikipedia.org/wiki/BDUF" rel="noreferrer">via Wikipedia</a></p>

<p>UPDATE: To clarify the question, I think I can also state it this way and keep my meaning:</p>

<p><em>"In what ways do you, as an Agile practioner, find the right balance between "quick and dirty" (unintentionally risking Technical Debt while attempting to adhere to YAGNI) and over-engineering (BDUF) <strong>within</strong> each iteration?"</em></p>

I find Robert Martin's
Test Driven Development
(TDD) approach helps with these concerns.
Why?
You only have to write enough code to pass the next test.
I think testable code is cleaner.
The design has to feed into tests which can help keep the design focused.
When you do have to change (refactor) you have tests to fall back on
Regardless of when the test are written (before or after) I find writing 
the test helps you make practical decisions. E.g., we picked design A or B because 
A is more testable.