Simplify vs Manage Complexity

Here's the difference between simplifying and merely managing complexity.

The Better Option

Essential complexity is inherent in a domain. It won't go away. If you're going to solve the problem, you must face it and deal with it. Or change the paradigms of the domain itself so that the essential problem changes.

Accidental complexity is that which can be avoided but isn't. It sticks around. Or is brought in as a part of our solution to the problem.

The simplest solution would be one that solves the essential complexity of the problem without introducing any new complexity. This is rare. It is the most elegant. Best products in quality and longevity. Best teams in the same. Simplicity is the better option.

To Simplify

To simplify is to take something away. There is a removal. The net change is deduction.

The elegance comes in doing more (solving the essential problem) with less.

As an example: The purpose of the blog is to write for my own joy and future reference and hopeful use of others. Remove general-purpose web framework, minimize 3rd-party integrations, simplify runtime, change design to still be fun but not require as much image development.

To Manage Complexity

Managing does not take something away. It makes that something easier to deal with. Simple vs. easy.

As an example: Our local build takes forever. We add a new tool that decreases build time through smart detection of where code changes have happened.

Perhaps another: Our tests make too many requests to our vendors, making them mad and our tests take a long time. We introduce stubs for fake test data and flags to unfake tests only in certain environments.

The Pain of Simplicity

To take something away is painful. For example, that build is doing great things for us. It lints, it spell checks, it runs all the tests, it compiles, it installs dependencies, it creates test environments. We like all that. It has value.

Yes, all that build code does good stuff. There's nothing not to like. If we took away linting, spell-checking, testing, compilation, installs or environments, we'd feel the pain. It's hard to like simplicity.

Whose Problem?

The essential problem of the domain is the user's. The solution should also be focused on solving that users' problem. Software that directly solves the problem of a user introduces essential complexity in the software nad processes to use it. This can't be avoided. (Though non-software solutions to the problem should also be carefully investigated.)

But software creation easily introduces problems that weren't in the problem domain before. They are accidental to the process of software creation or its use. The potential list here seems long. It likely includes team management like shuffling people around, project management like the sequential working of tickets over time, quality management like preventing, detecting and fixing bugs, release management like preparing release candidate code and deployment environments. And on. Management. Not user problems. Often accidental complexity.

Non-deterministic Opinions

Simplicity is the best way to deal with complexity. All complexity. Get down to the essence and solve it.

But who's to say what complexity is essential and accidental? We'd each have different answers. One person's "simple" will actually be a bad solution to someone else, not solving the essential problem. One person's "complex" will actually be the only path to solving this problem.

As a whole, the software industry definitely seems to tend toward complexity. Resumes to build, salaries to justify, tools to sell, courses to teach.

Clearly, there's an art here. There will be tension between simplicity and complexity on most attempts to solve a problem through software. Listen to perspectives. Favor simplicity. Remember the problem we're trying to solve.

Otherwise, we'll end up with an engineering OKR like: Build to Scale: Support 10x traffic in 5 years.