Simple is better where you need to maintain control, because then a human being can understand the entire system and its behavior becomes deterministic from our perspective. Complexity--practically by definition--means that the system's behavior becomes harder to predict, when software development is (in most cases) explicitly focused on delivering expected behavior. So for most practical software development purposes, simplicity is better.

But complexity can also be emergent from the aggregation of many small, simple components. E.g. the internet, which grew out of some relatively simple protocols connecting a handful of computers into the globe-spanning organism that it is today. So you may not design a complex system as a software developer, but your simple system may become a component in a larger, complex system. And that system will be more robust than the individual, simple components are. Such as the replacement of HTTP with HTTPS at the protocol level or fiber replacing copper in the physical system of the internet. Those simple systems have (or rather will soon) perish, while the more complex system that emerged from them survives.

> Such as the replacement of HTTP with HTTPS at the protocol level or fiber replacing copper in the physical system of the internet. Those simple systems have (or rather will soon) perish, while the more complex system that emerged from them survives.

Funny you should say that w.r.t. to reliability.

I just got back from vacation today and have just had 2 SSL-related issues I needed to solve, not to mention one related with dependencies on smaller components, which when updated broke my chain of software.

All these would have worked more reliably 1. without HTTPS and 2. if everything were packaged together :)

In short, the simpler solution would clearly be more reliable here.

Sure, but that's your experience as an individual developer on a small component of the system. If we're looking at the health of the system _as a whole_ (of which you, and the work you're doing to solve these issues, are a part), it's completely resilient to this change.

> Those simple systems have (or rather will soon) perish, while the more complex system that emerged from them survives.

I've wondered whether that is why we find ourselves surrounded by complex software. Legacy code is code that provides more value than the cost of its replacement. Bad code endures when that cost goes up.

Simplicity is especially important for developers because it is perhaps the most important determinant for the cost of reviewing, understanding and maintaining code.

But this cost association might be sort of special for systems built with code. Or systems that are built for handling discrete use cases rather than for continuous or approximate use cases.

This is quite speculative and a bit out of depth but: For some systems it might make more sense to duplicate a lot of functionality and use redundancy to achieve stability. Thinking of evolutionary systems for example.

> But I strive to make everything as simple as possible, remove unnecessary components, etc. I still cant understand contexts where complex is better than simple

If there are some, I'm not really aware of them. Systems we create should be human-manageable. The thing I find interesting is that, even with decades of attempts at better practice, we still end up with complexity that makes our work difficult.