Cure

---

As was mentioned earlier, the earlier the weakness of the foundation is discovered, the easier it will be to fix. However, not all hope is lost no matter when the problem is discovered. There is always a chance to fix the problem, but be careful not to look for hacked solutions. These will only fix the problem temporarily and in the end will worsen the situation. Instead, what is called for is a careful and considered approach.

Stop

The very first step to fixing a weak foundation is to stop development. Do not add any more features, and do not attempt to fix bugs unrelated to the foundation. Take a step back from the code and examine the problem or problems that are manifesting repeatedly. Continuing to develop will introduce new code that uses the weakened foundation even as the foundation is changing. This will lead to more errors and lost development time due to the difficulty of coordinating these two separate efforts.

Instead, the team resources should all be directed to fixing the foundation first. If some of the programmers cannot contribute to this process, find work that is not directly related to changing the application. This can also be a good time for them to spend time researching material for use later in development. This will derive at least some benefit from the time lost refactoring the foundation.

Learn

The next step is to determine what sections of the foundation are causing repeated problems. The goal of refactoring the foundation is to prevent more problems from occurring, and this can only be done by analyzing the current problems. It is important during this step to resist the temptation to make changes, as these changes might only fix one of the symptoms and not the disease.

Once all the symptoms that lead to the suspicion of Brittle Bones are collected, foundation changes can be considered to fix both the symptoms and likely future problems. This requires some extrapolation and is one of the reasons for collecting all the problems together. Much can be learned from similarities between symptoms, and this can lead to a shared solution. The more symptoms a single solution cures, the more likely that solution is to prevent future problems.

Refactor

At this point, you should have a list of possible solutions to implement. Now the actual refactoring must be done. Start by prioritizing the solutions in order of their impact; the more a solution is expected to fix the earlier it should be implemented. Now implement each solution one at a time. After every solution is implemented, test that the application functionality has not changed and that the solution fixed the expected symptoms. By keeping a tally of the symptoms that are fixed, you can be sure that all necessary problems are removed once the refactoring is complete.

---