I'll take a stab in this context:

Complex - many parts (but the parts could potentially be simple) Complicated - have to understand many things in order to understand it at all; large surface area

> it’s the same word!

I guess if you take the square root of -1 you do get a complicated number, but it's a complex one. And then there's the complication for modern democracy called the military-industrial complex, and Oedipus's complex certainly complicated things. Then there's Ghost in the Shell: Standalone Complex, but I'm not really sure what that means.

Seriously, here's the best summary I can quickly find: [0]

"Complicated problems can be hard to solve, but they are addressable with rules and recipes, like the algorithms that place ads on your Twitter feed. They also can be resolved with systems and processes, like the hierarchical structure that most companies use to command and control employees.

... Complex problems involve too many unknowns and too many interrelated factors to reduce to rules and processes. A technological disruption like blockchain is a complex problem. A competitor with an innovative business model — an Uber or an Airbnb — is a complex problem. There’s no algorithm that will tell you how to respond.

This could be dismissed as an exercise in semantics, except for one thing: When facing a problem, says Nason, managers tend to automatically default to complicated thinking. Instead, they should be “consciously managing complexity.”"

Those are very different problems for software development too, and many in IT definitely try to treat every problem as complicated.

[0] https://sloanreview.mit.edu/article/the-critical-difference-...

A complication on a wristwatch is anything other than telling time. Phases of the moon? Tides? Calendars? Complications. They make the innards more complex and fragile and difficult to build and repair. Complexity is the inherent difficulty in building the thing.

Together, what that's saying is that sometimes the minimal baseline complexity is going to be pretty high. If you're making a library to support all of HTTP/2, it's going to have lots of codepaths, and that's unavoidable. It's a complex problem requiring a complex solution. But consider SMTP, the "simple" mail transfer protocol. The protocol itself is stupidly simple. I can use — and have used — telnet to port 25 to send email. But because the protocol is so simple, implementing it is extremely complicated. Were the protocol a little more complex, the implementations could be vastly simpler.

Or perhaps more simply, if you're writing a textual protocol, define it as using UTF-8 encoding and move on. UTF-8 is more complex than simpler encodings like ASCII. Allowing your clients and servers to decide that they'd rather support something goofy, like Shift JIS or UTF-16, just makes everything vastly more complicated. Accept that the complexity of UTF-8 is inherent and sufficient, pay the cost, and then let all of your consumers be much simpler.

See also, Constraints Liberate and Liberties Constrain

[delayed]

The two words are both centuries old, so have had many chances for various authors and fields to adopt them for differing purposes, sometimes in contradictory ways. So for example a "complex system" (in the sense of the Santa Fe Institute) means something moderately different than what Tim Peters means. In plain English, they are broadly synonymous, so if you were writing a newspaper story you shouldn't expect readers to find subtle differences between them.

But if you know somewhat what implication a particular writer intends in drawing a distinction between the two words, then there's no inherent problem. "Simple is better than complex. Complex is better than complicated." is a pithy way to express a valuable idea:

We should try to make our interfaces, data structures, implementations, systems, etc. "simple", that is, dealing with just one thing at a time, in a clear and straightforward way, with few components each with a clear structure and purpose, etc., but sometimes there is inherent difficulty in a problem or in the world requiring many interacting pieces, but we should still aim to avoid making things "complicated", that is, tangled, messy, difficult to reason about, ambiguous, unpredictable, gratuitously mixing unrelated concerns, etc.

Complex = a problem that's inherently difficult to solve due to its fundamental nature. Time is a great example.

Complicated = a solution that's difficult to understand due to a convoluted implementation. These can be simplified.

In other words, the difference is whether the difficulty is inherent to the problem space (complex) versus inflicted by a solution (complicated).

If complex only refers to inherent complexity (and not accidental complexity and whatever other attributes were used by people before) then how is "simple is better than complex" to be read? If complex is inherent to the problem, does it mean "solve a different problem"?

It's generally a tradition for wise adages to be a little ambiguous leaving interpretation to the reader. I think that's as much a feature as it's a bug. Perhaps he meant it that way.

to complicate = to make more complex

If something is complex, you have to deal with it. But to complicate things is to be avoided.

A lot of words in English are etymologically related but have grown significant connotative or denotative differences since the root word was reintroduced to the language by another path.¹ "Complex" and "complicated" are just such a pair. They are not the same word.

In this case you can think of "complex" as referring to essential complexity and "complicated" as referring to incidental complexity.

----

1: See also, for example: "intention" vs. "intension", "chief" vs. "chef", "hotel" vs. "hostel", "corpse" vs. "corps", "compliment" vs. "complement", etc. Sometimes related pairs do the opposite, entering with distinct denotations and developing overlapping ones e.g., "intellect" vs. "intelligence", and some include overlap but have had specialized senses come to dominate, e.g., "dispositive" vs. "dispositional".)

If you wanna get your head around English (or probably any language), the intuition that alerts you to related words is a very useful sensitivity, but you have to learn to absolutely resist the temptation to treat etymologically related words as identical. It's just not how language works. English seems like it might be especially rich with these "etymological doublets" (thanks ChatGPT, for teaching me this word today). They're really useful for capturing distinct shades of meaning between closely related concepts, which is exactly what they do in this adage from Tim Peters.