That is a strange and "unnatural" (for me) use of the word "complicated". Cynefin[1] defines 'complicated' as "known unknows" and 'complex' as 'unknown unknowns'. The idea is that complicated things are non-obvious, but they are understandable (with expertise, you get the relationship between cause and effect). With complex, full cause & effect cannot be known apriori, it's just observable after the fact.

That somewhat resonates with the definition that complex (code) is about intertwining - 'complex' is problematic because as things get more and more complex, you can have only a local understanding, and can't possibly hope to grasp all the implications of a code change. This suggests that "complicated" is something that is "somewhat complex, but still manageable with sufficient expertise/domain knowledge". I tend to use "complicated" to denote something that has inherent complexities (due to the nature of the real world); and "complex" to denote something that is artificially complex, due to ... well, lack of thought into making it as simple as it could be. In that sense, I view "complex" as being definitely worse than "complicated"

[1]https://en.wikipedia.org/wiki/Cynefin_framework

I see it the opposite way. Some things are inherently complex, like heart surgery or launching a rocket. There are many things that have to work together perfectly or the whole thing goes south.

Complicated to me means that complications have been added where they weren’t needed. A Rube Goldberg machine solves a simple problem that has been complicated.

I've come across these meanings too, and they're the ones I use.

Complexity is a property of the problem; complication is a property of the solution. Whilst over-complication is bad (e.g. your Rube Goldberg example), so is being simplistic (not enough complications to handle the complexity).

Examples of simplistic solutions can be found in all of those "What programmers don't know about FOO" articles (human names, timezones, distributed systems, etc.)

That's a great point. I've given approximately zero thought to this, but would you say TDD (or any other requirements-driven design process) would avoid that kind of oversimplification?

> would you say TDD (or any other requirements-driven design process) would avoid that kind of oversimplification?

I haven't thought too much about how such things relate, but my first thought is that TDD seems biased towards oversimplification, since we do 'the simplest thing which makes the tests pass'. If we're testing that Bob's user profile shows the name "Bob", then the simplest thing is to have all profiles hard-coded to say "Bob". To fix this, TDD tells us to add more tests which check different names. That's before we've even begun to consider the hairy details of how names are used in different cultures.

It's a reasonable approach, but it's not "solving" the oversimplification problem, it's just shifting it into the test suite. It's similar to the problem of over-fitting in machine learning models, where we may need millions of input/output examples to narrow-down the intended behaviour.

I think the aggressive refactoring advocated by TDD manages to bias it away from overcomplication.

TDD should give you the simplest solution conforming to your spec (your tests). So it's all the necessary complexity without any unnecessary complexity to fulfill your testsuite, and ease of refactoring in case you need to change something more fundamental about your code.

At some point you need to specify which edge cases you need.

> it's all the necessary complexity without any unnecessary complexity to fulfill your testsuite

As I said, it doesn't solve the problem of overcomplication/simplification, it just shifts the burden on to the test suite instead of the program.

Hmmm... I looked up word origins. "com" + "plicare" - "to fold together". You seem to be right, it's closer to the original meaning to use them like you say ("complex" = inherent complexity; "complicated" = "incidental/ added complexity"). I can't reconcile it with Cynefin, but I'll have to update my usage of those terms in a coding context.

I've had this conversation with few people - mainly peers with whom I'm discussing our craft. Most recently it was with a junior engineer, and I wanted to pin these definitions down precisely so that we had a common vocabulary for describing ideas we were developing. I mention this because I haven't heard these terms commonly used in any particular context so I don't think there's an agreed upon "correct" definition of them. I think my definitions more closely jibe with the normal English meanings, though.

I'd say don't try to use Cynefin's definition to understand what the PEP authors means. (Un)known unknowns is a pretty terrible definition of those words, it doesn't really match the common definitions at all.

Complex and complicated are, according to the dictionary, basically synonymous, and they mean something intricate or tricky that is composed of many interconnected parts.

I think the PEP authors were trying to say it's better for a piece of code to be clever and tricky to avoid complicated interactions with other code, if that's your only choice. I think they're trying to suggest complexity at a small scale is better than complexity at a large scale. But I'm just guessing, and I do think it could be better stated with two words that aren't synonymous.

In a uni course a while back they did define complex as something that can't be understood, and complicated as something that is understandable but hard.

So I agree with the above poster that the PEP makes no sense here.

Complex does not mean something that can't be understood. Like Cynefin, your uni course might also using bad definitions, if they meant those definitions for the general context. If they were giving you domain specific definitions, like in a math course or something, then your applying it to this situation might be your misunderstanding. We have dictionaries for just this purpose, so that we all agree what words mean. Words also have multiple meanings, so while it may be true that what the PEP authors said makes no sense to you, it's best if we avoid egg on our faces by calling someone else wrong if the problem is that we didn't take the time to understand what they meant, or assumed incorrectly that our understanding is the only one possible.

The common definitions of complex and complicated are that they're synonymous, there is no strong or fundamental distinction between them in the way you're trying to suggest. That's the main problem with the PEP statement. Trying to assert there's a difference is likely to result in miscommunication, this uni course and the PEP authors are both making the same mistake.

adjective 1. composed of elaborately interconnected parts; complex: complicated apparatus for measuring brain functions.

http://www.dictionary.com/browse/complicated

https://en.m.wiktionary.org/wiki/complex

https://en.m.wiktionary.org/wiki/complicated

https://www.merriam-webster.com/dictionary/complex

https://www.merriam-webster.com/dictionary/complicated

https://dictionary.cambridge.org/us/dictionary/english/compl...

https://dictionary.cambridge.org/us/dictionary/english/compl...

It seems more to be based on personal agency. If youre going to make something, make something simple. But if you can't, it is better to make something complex (opaque by scope), than to make something complicated (opaque by architecture).