Low Inertia

Because software is immaterial, it should have zero weight. But this isn't true. In software there is no space constraint as with material goods, so software complexity and module interdependencies are unlimited and can be extremely high. Thus, systems can be very difficult to change and consequently very heavy. XP strives to keep the system inertia (complexity) as low as possible. The practices related to this feature are these.

• Simplicity. The system must be kept as simple as possible. Only the features that are actually needed must be implemented, with no provision for possible future reuse. When a new feature is needed, it can be implemented easily because the system is simple and well understood by its developers. Traditional software engineering, on the contrary, strives for reuse, and it is customary among programmers to develop features that could be useful in the future. XP prohibits doing so. This is the main rule for having a system with low inertia.

• Refactoring. The system must be continually improved and made clearer, simpler, and less redundant. This process is called refactoring and must be applied whenever the developers realize that it is possible. Automated testing ensures that nothing will be broken by these modifications. Refactoring, too, enables having systems with low inertia.

• The documentation is the code. Avoiding big up-front analysis and design and avoiding having many design documents that must be kept aligned with the code are popular among programmers and reduce the complexity of the overall system (documentation plus code). To be effective, however, the code must be simple and continually refactored, and must reveal the programmer's intention.