When you have a new project and the project could last very long, consisting of thousands of lines of code to be changed, added, or deleted, would you break it down? Of course, it could be much easier to do the breakdown of the task into subtasks and do it, one by one, function by function, and do the unit test for each of the modules. Separately.

For example, the monthly payout system (e.g. the system for salespeople with commissions, any accounts with interests, online ads publishers, etc) could consist of the calculation part and the money transfer part. And the money transfer part could be broken down into the account setting (the panel for the admin or account owner to update the transfer channel and/or account number and the APIs that connect to the banking service. This is very big already.

Say, if the calculation itself takes 2 weeks to implement, and the admin panel another week, and three internet banking APIs to connect to, and one another panel to record the offline payment. The whole project could probably take 2 months or around 4-8 sprints.

Anything could slow this project down?

1. Merge master into the development branch

The merge could cause conflicts in the code at any time if we do not plan the project well (if we pick the projects that are relevant to the ongoing project, of course, there is a very high chance of conflicts). And for the payout system which would take the data from the main table like the sales (for the salespeople to get the commissions), the ads_publication_history (for the online ads publishers), anything could occur.

And one worst case that could happen to your branch when you merge the master in. If the master does not contain the big update that you added at the beginning of the project but someone else updated something in the same file after that without causing conflicts, the new master's file without your change could be replacing your copy, leading to the loss of your code. And you know, this is not preferable at all.

2. Missing codes or missing features

If the project is too big and everything was located within one development branch, you only have the commit messages that keep tracks of all your features, but it could be something like "feature 1 commit 1", "feature 1 commit 2". Hence, it's very hard to keep track of all the features. How are you going to make sure you don't miss out on any features?

Moreover, because of the loss of code that could happen during the merge, you won't be able to count that every change from all your previous commit messages is there in the branch.

3. Difficult to review

When you create the pull request for a thousand lines of changes in hundreds of pieces of codes, no one wants to read them! When the reviewers are fatigue, they could probably skip some parts of the code, either intentionally or unintentionally. And the riskiest thing is that it is very difficult for them to catch all the errors that are hidden in the ocean of red and green lines of code that became spaghetti in your pull request.

4. Difficult to Investigate when Anything Goes Wrong.

And anything that can go wrong will go wrong. If your development branch is small and contain only your small feature, it could only be the only small pieces of code that could go wrong and hence it could narrow down the problem significantly. Imagine the branch is ten-thousand lines and when anything crashes, you have to investigate the whole big change.