It seems to me that there are a few people who aren't to sure of what OOP really means. So, I've decided to attempt to focus the next few entries on OOP and some of its core principles. I will frequently attempt to provide googling terms, but I won't guarantee that.

Why you should fear RFIV
Your design is rotting. Well, maybe your's isn't, but I can guarantee that someones is. So how can you tell if your design is rotting? You will typically find many different symptoms indicating that your design is rotting, but here are the most common ones:

• Rigidity
  You find indications of this when you attempt to make a small change and find that it ends up cascading through several modules. Very much like a recursive function, you keep having to move from module to module making changes to accommodate for your one original change. Like a dog chasing it's tail, you continuously find yourself moving from module to module. This typically crops up when you need to add new features, or when you need to make a small change to fix a bug.


• Fragility
  This one is tightly related to rigidity. This particular symptom crops up when you make a minor change and find that other modules break as a result of the change. Quite often you will find that the code will break in areas that seem completely unrelated to the change in question. Fixes that are applied to solve the breakage will typically increase the fragility of the software, hence making it even harder to change and keep working.


• Immobility
  Code that is immobile is code that cannot be reused. This doesn't just mean code that cannot be reused in other projects, but even local project reuse. A programmer may find that he needs to do something similar to what one module does, but that he can't use that module due to dependencies that have snuck their way into the other module. This code no longer can be reused (if it ever was) and hence makes for duplicated code elsewhere. This tends to increase the chances of bugs, and makes the software more rigid and fragile in the process.


• Viscosity
  You will find a high viscosity in code when you cannot make a design preserving change more easily than a hack. Hacks inheritly break the design of the code, they also tend to increase immobility and fragility. Viscosity can also be an environmental factor. For instance a large C++ project will typically have long compile times, which can account for slow development (and debugging) thus contributing to a high viscosity in the environment.

Why is your design rotting?
The most prevalent cause for design rot is the case of changing requirements. Changes that were not initially predicted have been requested. Since the changes were requested at an inopportune time they took place rapidly, and tend to violate the principles of the original design. While the changes work, they contribute to the increasing entropy in the code. As these changes accumulate over time, the entropy continues to increase and the design continues to rot. Eventually the code bites back and things cease to work anymore. Welcome to hell.

The cause of all of this rot, and increase in code entropy, is a failure to properly account for your dependencies. Unnecessary dependencies are introduced. As each module becomes more dependent upon the other, changes to one cause others to break, and when those are fixed, they in turn cause other modules to break. Each fix introduces a new dependency, and hence increases the rigidity and fragility of the software.