Symptoms of Design Rot

Sometimes it’s just a feeling when looking through some code. Perhaps something you’re working on feels ‘hacky’, or has ‘that smell’. Or perhaps things seem to be moving so slowly that it feels like pushing features through taffy. Or Maybe things just fall apart too easily. There are many reasons to take a step back and review your code. There are, additionally, many reasons an organization may want to do the same. It is really hard to sit through a code review. It is also difficult for an organization to put on the brakes and do a thorough self – analysis. An audit generally sucks. The great news is that a code base is not supposed to get these aspects right the first time around. I’d personally call it a fact that things can be ‘over engineered’ or ‘over architect-ed’ more specifically. Taken too far, these ‘rules’ can be overbearing, inefficient, and near impossible to do to their fullest extent. So, it is important to understand why people rewrite code and what are some of the signs and a true north for how to affect good change in a code base. That’s why talking about software architecture is so interesting. Working through this architecture stuff provides real and measurable benefits to both the workers and the organizations themselves.

What are signs of a system in need of some review?

Everything below is taken from my reactions to Design Principles and Design Patterns, by Robert C. Martin. This PDF can be found all over the internet.

1. Rigidity
   • The system is difficult to change, even in simple ways. Every change seems to result in a cascade of changes in dependencies. 
   • What was thought to be a short sprint turns in to a marathon.
   • Managers begin to be reluctant to allow engineers to fix non-critical problems, since they cannot know reliably when an engineer might be finished. Tasks are claimed, but take longer and longer to check in. 
   • When these fears become very acute, official rigidity begins to set, and becomes management policy. 
2. Fragility
   • Related to rigidity. Fragile systems break during changes in strange ways. There may be no conceptual connection to the parts of the system break when changes are made.
   • As fragility increases, the probability of breakage increases, eventually resulting in systems that impossible to maintain. Every attempt at repairs results in more problems. 
   • At its worst case, distrust reigns in the organization.
3. Immobility
   • The modules are not reusable, or difficult to reuse. 
   • A sign of immobility is when an engineer wants to reuse a module, but the module has too much connectivity that it depends on. After a lot of work, the engineer might discover that the work and risk to separate the desirable bits from the undesirable is just too much work. 
   • Usually the module is simply rewritten in this case. 
4. Viscosity
   1. Changes to this project move like molasses! 
   2. Two types of viscosity are in the design or in the environment. 
   3. Generally, if it is far easier to corrupt the design than it is to stick to it, then the project is more viscous. 

These issues arise because of changing requirements. It is well understood that requirements changing beyond the ways the initial design document did not anticipate creates issues. Frequently, integrating these changes are required to be made quickly, and might be made by engineers not familiar with the initial design philosophy.  If the design is failing due to a constant rain of changing requirements, the reality is that our designs are at fault, and that we must, as engineers, make our designs more resilient. We can do so with proper Dependency Management. In order to prevent the degradation of our dependency architecture, the dependencies of modules must be managed using dependency firewalls.