Essential complexity: Difference between revisions

Revision as of 01:26, 17 July 2014

Revision as of 03:26, 17 July 2014

Line 1:

{{split|date=July 2014}}

'''Essential complexity''' has been defined in various ways by various people. One definition is as an antonym to [[accidental complexity]]. Another definition is a number attempting to measure how close (or far) a given program is from being a [[structured programming|structured program]].

== Antonym to accidental complexity ==

'''Essential complexity''' refers to a situation where all reasonable solutions to a problem must be complicated (and possibly confusing) because the "simple" solutions would not adequately solve the problem.{{cn|date=July 2014}} It stands in contrast to [[accidental complexity]], which arises purely from mismatches in the particular choice of tools and methods applied in the solution.

This term has been used since, at least, the mid-1980s. [[Turing Award]] winner [[Fred Brooks]] has used this term and its antonym of [[accidental complexity]] since the mid-1980s. He has also updated his views in 1995 for an anniversary edition of ''Mythical Man-Month,'' chapter 17 "'[[No Silver Bullet]]' Refired".<ref name="Brooks, Proc. IFIP" >[[#Brooks, Proc. IFIP|Brooks, Proc. IFIP]]</ref><ref>Brooks, IEEE Computer</ref><ref>Brooks, Mythical Man-Month, Silver Bullet Refired</ref>