Given that working features are better value for a company than good code at any given point in time and that bad code makes adding more features difficult:
How do you stop the code from deteriorating over time?
At any point, getting a feature to work is higher priority than getting it to work with well engineered code which takes longer. Even though as time goes on the effort for each feature increases.
How do you stop the code turning into an un-maintainable mush over time?
A comprehensive set of unit tests
edit: and it's helpful if they are well written to accurately test all your classes / interfaces in a human readable way.
edit 2: as svelil says, refactor your code to keep it clean, but being able to do this is a consequence of having the unit tests.
A decent set of coding standards.
They don't need to be complete, but they should mean that you know what things like your brace-indentation is so you have less to think about (and it means that places where the code was rushed and not formatted properly will stand out like a sore thumb)
Periodic refactorings, particularly in the section of code in which you're currently working (the "Boy Scout" rule).
Use an iterating development process:
You have to have some discipline, but without it you will end up having a mess. Even if you think "Oh, the code is readable enough", don't skip step 2. Of course, development should always be accompanied by testing.
The top and accepted answer in this question should be "Comprehensive unit tests".
This answer is not going to repeat that.
However adding Unit Tests to an existing project is much harder and generally is poor imitation of what can be achieved if the application code it self were written with Unit Testing in mind.
Also extreme schedule pressure can make it impossible to consider, those who haven't experienced using unit testing its still a big punt.
My recommendation in those conditions is write as well as you can to achieve the current goals. Be prepared to refactor existing code before adding new functions. Whilst unit testing would make this approach way way safer, this approach is still useful even without unit testing.
Of course good general testing and QA is important.
Unit tests will not stop the rot on their own. I can still write horrendous, unmaintainable code that passes a unit test.
A better answer is unit tests. + regular refactoring + peer review (either at pairing stage or after) + standards
You do know there is no silver bullet.
In my job, as we approach code freeze then the 'fast and dirty' approach is sometimes necessary. This usually results in some pretty dodgy code that works but offends thine eyes.
However, immediately after shipping there is a period of relative calm. This is the perfect opportunity to revisit some of that smelly code and knock it into a bit of shape.
It helps to keep a list of areas that you would like to tidy up and assign some sort of priority to them. Despite how good you believe your memory to be, you WILL forget.
This approach works quite well for me but I suppose it depends upon your particular project workflow.