The two most popular XP practices that seem to be adopted by various teams at Microsoft are test-driven development (TDD) and refactoring. The developers I have spoken to who have used the TDD technique swear they would never go back to the traditional "write first, test later" process. They say that by writing the tests up front, they have fewer bugs in their code when they are close to shipping. The only difference I see that they do from what is prescribed by Kent Beck is that the Microsoft testers write their tests at the same time they write their production code, not before they write their production code.
Refactoring is the process of rewriting written material to improve its readability or structure, with the explicit purpose of keeping its meaning or behavior.
In software engineering, the term refactoring is often used to describe modifying source code without changing its external behavior. It is sometimes informally referred to as "cleaning it up." Refactoring is often practiced as part of the software development cycle: Developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Testing ensures that refactoring does not change the behavior of the code.
Refactoring is the part of code maintenance that doesn't fix bugs or add new functionality. Rather, it is designed to improve the understandability of the code or change its structure and design to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program's given structure, so a developer might refactor it first to make it easy and then add the new behavior.
Refactoring has been around Microsoft for years. I know when I was in the NT group in 1991, developers were refactoring and optimizing their code as needed or as a general practice, and this was in the early days of the product when the code was just being written.
The following is an explanation taken from http://encyclopedia.laborlawtalk.com/Extreme_programming:
You can go about using TDD in various ways. The most common one is based on KISS (keep it simple, stupid) or YAGNI (you ain't gonna need it). This style focuses on writing code any way necessary to pass the tests. Design and proper principles are cast aside in the name of simplicity and speed. Therefore, you can violate any rule as long as the tests will pass. This can be unsettling for many at first, but it allows the programmer to focus only on what is important. However, the programmer pays a higher price in the refactoring step of the cycle because the code must be cleaned up to a reasonable level at this point before the cycle can restart.