A phrase from an interview of BjarneStroustrup on SlashDot, http://slashdot.org/article.pl?sid=00/02/25/1034222 . See question number 9.

''Of course, the statement assumes that all complexity is inherent.  Time for a reread of NoSilverBullet and thoughts about EssentialComplexity and AccidentalComplexity.  ---GlennVanderburg''

From the context, I got the (subjective) impression that he ''was'' referring to essential complexity. YMMV. --FalkBruegmann

He was almost certainly referring to complexity that he saw as essential; it would be silly for him not to be.  There is a question as to whether he is correct about that; I used to think so, but I'm pretty sure it's the other way these days, and that at least some of the complexity referred to is artificial. -- GrahamHughes

Nevertheless, I get the impression that he is right. The complexity of a program comes from two places: (1) the complexity of the problem the program is intended to solve (EssentialComplexity), and (2) the complexity of the programming language, the virtual machine, etc. (AccidentalComplexity).

Sometimes, a programming language can eliminate much of the complexity of a program because it already has a library that is close to the problem domain. Sometimes, the programming language has few libraries, but it allows you to organize your code in such a way that the complexity is manageable. Some programming languages (such as pure assembly) do not provide facilities for you to organize your code; your organization must appear in the form of comments and spacing and is not visible in the language itself. And sometimes a RestrictedProgrammingLanguage has been designed under the assumption that you will never need to organize the complexity of your program in the way you are thinking, and that the language should prevent you from organizing it that way. -- EdwardKiser

----

What are the techniques that can get rid of essential complexity? Ignoring of course that what is artificial and what is essential is a judgment call.

''Reduce scope.''

In particular, make sure you understand what the customer really wants, which may be much less than you imagine.

''Delay doesn't decrease complexity.''

''Sounds like a trick question.  If the complexity is "essential," then of course it cannot be eliminated.  I, find, most complexity is not essentially, but either an explicit choice or forced by lack of knowledge of an alternative.''

[Use better models/abstractions.  Complexity can be a sign that you're using the wrong tools.]

----

I have shoved complexity into EmergentBehavior before. That leads to quite impressive results. It's also nice to eat complexity with function pointers (or Delegates in DotNet)