I think it is normal in a project to accumulate technical debt somehow. You may have tough deadlines or other reasons to tend get things done more quickly than usual, probably with the mindset of getting it right later.
Other reasons for (quick) workarounds are new awareness (more experience) of how things work better under certain circumstances. The old approach was good for one particular problem, but not good enough for a general solution.
An increasing number of developers working on the same project may force the architect to enforce new coding guidelines or best practices for typical software development problems.
The use of embedded third party software may also trigger changes on your side when updates are delivered.
Technical debt should be avoided as much as possible and yes, there are scenarios where you are simply forced to live with technical debt. But, one should always be aware that, often, the time to improve old code won't be availble. Even if there will be such time, think about the risk of removing technical debt. Someone who works under pressure not only tends to seed ugly workarounds, but he is likely also adding sloppy unit tests (if he adds any at all). If that's the case, removing technical debts with refactored code adds new risks breaking functionality you won't know about until the customer reports them.
