For example, a singleton is easy to learn and easy to use, but since every function using it adds a hidden dependency it quickly grows in complexity to the point its impossible to reason about it without forgetting something.
On the other hand, a Promise is simple as it depends on nothing but a producer and a consumer, no matter how much you compose them. Yet I've seen many experienced developers struggle to learn how to use them as they're not easy to understand at first.
This is somewhat related to meta ignorance. From my own experience I've seen a tendency in novice programmers to stick with things which are both easy to learn and use. Their projects go well initially but they grow less and less productive over time as complexity creeps in from the composition of all these easy to use things.
I've always said experience in our industry is knowing what not to use in order to stay productive in the long run.
Here's a link to Rich Hickey explaining it in depth: http://www.infoq.com/presentations/Simple-Made-Easy
Also note that english isn't my first language (I'm french Canadian) and even here in french the distinction is seldom made.
The distinction between two main types of simplicity, those of parsimony and elegance, has been a long-standing philosophical topic [1].
In engineering, the so-called KISS principle (first coined as such in the early 20th century) has always had the implication of minimalism and implementation simplicity, in contrast to mere ease of use.
Fred Brooks wrote a famous paper in 1986 [2] perfectly describing the differences between accidental and essential complexity, and of the semantics of complexity management in software projects.
Hickey has said absolutely nothing spectacular, but his name comes up every time from the typing fingers of the historically illiterate whenever simplicity and ease of use are brought up.
[1] http://plato.stanford.edu/entries/simplicity/
[2] http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...
Rich Hickey gained fame for this because he stated an idea very clearly and compellingly, this is non-trivial and should not be so flippantly dismissed as just recyling old ideas—all your ideas are recycled too.
+100 for this.
I knew about KISS, but almost every time I hear someone mention it they think about ease not simplicity. I will also definitely check out Brooks' paper.
While I understand your position, I believe a lot of this has been lost to the new generations of engineers and what Rich did is remind them of it.
In the parlance of Mr. Rumsfeld, you can learn from the known unknowns, but often you don't even discover the unknown unknowns (the "meta-ignorance") until it's too late.
This, like most engineering tasks, is more straight forward. You have to know what its going to take to build each piece and assemble them into the final product. So if you are making a AAA indie game, it helps if you can talk with the project manager at a company that made AAA games and go through their list of deliverables, and then think about how you're going to deliver the same thing. Sometimes you'll be tempted to say "we won't need to do that" but like Chesterton's fence, you need to understand why they did that so that you can really say you won't need to do that thing.
It is always ok to start with "how hard could it be?" but that starting point requires you educate yourself on exactly how hard it could be. For game development I think pretty much all the questions are knowable (except for consumer reception of course)
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."
I learned something new (and useful) today. Thanks!
Source: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
Yeah, it's descriptive. I think I re-purposed a term from an academic paper that referred to meta-stupidity: stupid people are too stupid to know that they're stupid.
They did an experiment where they got people taking an exam to guess what mark they were going to get. In general, the lower scoring people in the exam over-estimated their mark more than the smart people.
Part of why it's good to be cautious around self-proclaimed experts.
Its very easy to forget all the efforts invested in learning a skill when you've been using that skill for many years. When it becomes second nature, you assume its also that way for others.
The other aspect of this that I see, even in seasoned engineers, is the 'presumption of simplicity'. Some things look really simple, but inside they are actually quite complicated. A smart phone is just a screen, a computer, a battery and a radio right? Too many times people see something, think "that doesn't look too hard I bet I could do that in a weekend"[1] but don't actually follow through on that thought and spend a weekend building what ever it was that was so easy. Sometimes the more experience you have the more dangerous this is. I can recall times in my own life we're I've grossly underestimated the difficulty of stuff, its lead me to be a lot more conscious about things I know about and things I think I know something about, especially when predicting schedules and work effort.
[1] A very common theme on acquihire stories here.