Business Logic Is a Magnet for Complexity

While our code has to implement the necessary complexity, it can often be even more complex due to our decisions about how the logic gets implemented. For example, we may choose to manage user accounts in another application and make API calls to it. We didn’t have to do that, and our domain doesn’t require it, but it might be just the way we ended up building it. This kind of complexity is called accidental or unnecessary complexity.

We can never avoid all accidental complexity, but the distinction to necessary complexity is important, because we do have at least limited control over accidental complexity. The better we manage that, the better able we are to manage the code to implement the necessarily complex logic of our app’s domain.

What this means is that the code for our business logic is going to be more complex than other code in our app. It tends to be a magnet for complexity because it usually contains the necessarily complex details of the domain as well as whatever accidentally complexity that goes along with it. To make matters worse, business logic also tends to change frequently.

Business Logic Experiences Churn

It’s uncommon for us to build an app and then be done with it. At best, the way we build apps tends to be iterative, where we refine the implementation using feedback cycles to narrow in on the best implementation. Software is notoriously hard to specify, so this feedback cycle tends to work the best. That means changes, usually in the business logic. Changes are often called churn, and areas of the app that require frequent changes have high churn.

Churn doesn’t necessarily stop after we deliver the first version of the app. We might continue to refine it, as we learn more about the intricacies of the problem domain, or the world around might change, requiring the app to keep up. This means that the part of our app that is special to our domain has high complexity and high churn. That means it’s a haven for bugs.

North Carolina State University researcher Nachiappan Nagappan, along with Microsoft employee Richard Ball, demonstrated this relationship in their paperN. Nagappan and T. Ball, “Use of relative code churn measures to predict system defect density,” Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005., St. Louis, MO, USA, 2005, pp. 284-292, doi: 10.1109/ICSE.2005.1553571., in which they concluded:

“Increase in relative code churn measures is accompanied by an increase in system defect density [number of bugs per line of code].”