Today Rahim is happy because he has completed his functional module successfully. Also, the module has passed all the test cases. So he goes to his bed with a cheerful mind and thoughts. Unfortunately, the next morning when Rahim runs his code, the module is not working anymore!
If you face this situation like him that’s great, if not that’s also great. But Do you have any idea why the module doesn’t work?
However, In Rahim’s case, what happened is one of his team members Karim stayed later than Rahim and changed something that the module (Rahim’s written module) depends on.
Robert C. Martin called this circumstance “the morning after syndrome”. It occurs in a large team where many developers work on the same source codes. Actually, the dependency cycle is responsible for this syndrome. It is not a big problem in a relatively small team or small project.
So now the question is how can we avoid these types of problems. Generally, two solutions are popularly used to overcome this situation.
This solution can be used in a small project. It goes like this: all developers work separately for the first 4 days. During this time they ignore what other developers are doing. They only focus on their parts. On the 5th day, they all integrate each other's code. The big advantage is that the developers work isolatedly on those 4 days without any headache.
But integration time usually grows as the project size grows. Sometimes it is less feasible to finish integrating in one day. It may take 2–3 days or more than 3 days just for integration. As time goes, the integrating period becomes lengthened. The more you lengthen the period, the more project becomes risky. As a result, the team loses its working efficiency.
Another solution to this problem is to use the releasable components. Here, components can be treated as a unit feature which is the responsibility of a single developer or a team of developers. Whenever the developer or the team gets a working and releasable component, they share it with other developers to use. The other developers can merge or use it with their components if they feel the necessity. In this way, integration happens in a small increment when the developers get time or think this is the perfect time for integration. This process is simple and widely used.
Long story short, you should not have any dependency cycle in your development process otherwise the “morning after syndrome” can’t be avoided. Robert C. Martin named this principle as Acyclic Dependencies Principle (ADP). Wikipedia describes ADP as below,
The acyclic dependencies principle (ADP) is a software design principle defined by Robert C. Martin that states that “the dependency graph of packages or components should have no cycles”.
This is a short description of ADP. I hope this post would give you a clear gist about ADP.
Happy Learning!