A common issue that comes up on software development teams is that of managing complexity in what needs to be developed. There are two essential types of that complexity: essential and accidental. Effectively distinguishing between the two has deep repercussions in development, operational, managerial, and morale concern for years.

• Essential complexity refers to complexity that is inherent to the problem domain. For example, creating a tax accounting system for the United States has inherent complexity in handling different state’s tax laws.
• Accidental complexity refers to complexity outside the inherent problem domain and that a development team has created for themselves. A characteristic example of accidental complexity is unnecessarily over-abstracting in a codebase that results in its being difficult to modify, maintain, or onboard to. If you are operating only in Pennsylvania, trying to speculatively model for interstate commerce before you know what that entail is creating accidental complexity.

When leading a software development team, it is a useful group exercise to characterize the degree of essential versus accidental complexity. You may find that you are overreaching in domain modeling – or maybe even simply that the programming language chosen makes modeling your essential complexity harder than it needs to be.

The essential complexity of your problem domain will never go away unless your problem domain itself changes. Your accidental complexity can be identified and managed.

Eliminate your accidental complexity to the best of your and your team’s ability and you will have one less paper cut that can lead to death by a thousand paper cuts.

And – to speak to the “morale” comment above – we all have an intuition for what we shouldn’t have to deal with. Let yourself and your colleagues focus their talents on what you’re all there for – and not on made up bullshit.