Simplifying Complexity

Complexity is the enemy!

No. Complexity is not the enemy. The problem is the enemy, and complexity is a road block to solving it.

With that understanding, let’s dive into some types of complexity that come up:

---

Complicated Complexity

Complicated complexity is complexity which I most frequently see pop up from business rules. The business process is complicated, the code reflects the process, and so the code is complicated.

One of the biggest issues we see here is trying to simplify the complicated. We as developers might think: “This doesn’t need 15 steps, I can do it in 6!“. We simplify the complicated, and break things in the process.

The best question to ask in this situation is not “How can we make this simpler?”, but rather, “How can we make it simpler to work in the complexity?“.

Mismatch Complexity

This is complexity which arises from a mismatch in the stated purpose of an item and what it actually does. This frequently occurs from refactoring efforts that failed to address comments, didn’t update variable names, and so on.

The best ways to address it are to limit lifeless artifacts in your repository. For example, wikis comments which have no impact on the function of code are significantly more likely to fall behind than unit tests consistently ran.

And… this is an area that I believe could be strengthened as time goes on. I’ve loved efforts for automatic documentation generation efforts generated by schemas and types present in the code rather than relying on fallible comments.

Scaling Complexity

Scaling brings up new challenges to ensure high availability and consistency across the system. The nature of the needs means that new thought models are required to ensure that your system stays online.

Addressing these concerns upfront does wonders later. The consequence of choosing a particular architecture will stick with you for far longer than you probably wanted otherwise.

Some of the key principles in managing it are to keep domains internally cohesive and externally decoupled, preferring small over large, and using tools that work well together over “the latest new thing”.

---

When we talk about complexity, we are typically really talking about one of the 3 things above. Understanding which of the 3 helps inform what the most appropriate action is.

Ultimately, the goal is to make the system complexity as close as possible to the domain it models. Any more, and we risk over simplifying. Any less, and we have to deal with stumbling blocks rather than solving problems.