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.

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).

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 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.

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 well defined purpose, etc. Sometimes, however, 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.

to complicate = to make more complex

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

Simple and complex are two sides of the same coin. Both are everywhere in nature. Complication is something else, but how can you describe it? I can think of examples. Bureaucracy comes to mind. Locking and synchronization primitives too. The kind of fragile mechanisms in the Linux kernel that lead to endless CVEs are another. All man-made things!

> 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-...