From FredBrooks' NoSilverBullet. Accidental difficulty in programming arises from the tools and processes we use. It's not inherent in the nature of programming itself. Accidental difficulty can be removed by improving tools and processes. Brooks later said that maybe the name "IncidentalDifficulty" would have caused fewer misunderstandings. See also EssentialDifficulty.

In fact, it's probably easier to understand AccidentalDifficulty as the dual of EssentialDifficulty; or all that difficulty which is not essential.

Occasionally, people like to point up a tool or process or technology as a source of accidental difficulty. That's not exactly right. The accident is the arbitrary decisions that are required in order to get something done. Essentially, I want to sit. Accidentally, I grab a chair, or a tree stump, or a railroad tie, or a park bench. Accidentally, I have to find something sit-on-able and decide that it's a valid thing to sit on. Accidentally, I have to move my arse to the sitting-place.

There's quite a bit of the accidental in programming, but Brooks asserted that it's less than 90% of the programming effort.

''I believe Brooks insofar as believing that there is no '''singular''' cause for more than 90% of the programming effort across all domains.  I.e. there is no one thing to target with a SilverBullet.  That doesn't preclude that there are 'singular accidents' causing 90% productivity penalties in specific domains, nor does it preclude that the sum-total of all accidents across domains accounting for 90% or more of programming efforts, on average.  Indeed, once we start accounting for competitive NonFunctionalRequirements and communications between computational services, I wouldn't be surprised if 95% or more of what we encounter is 'AccidentalDifficulty'.''

''One question a programmer might ask is: if I had theoretically perfect tools (languages and IDEs and input devices and OperatingSystem''''''s and frameworks and libraries) and processes (methodologies, community, education, etc.), then, modulo the application-specific stuff, how many of me would I be worth as a programmer/IT person?  Ultimately, the answer to this question depends on the domain and the tools you already work with.''  

----

If one is seeing a lot of AccidentalDifficulty caused by boiler-plate code or hand-written translations to and from tools and interfaces, something in the system is likely SimplySimplistic.  SimplySimplistic models and services and interfaces are too simple, failing to capture the EssentialDifficulty, and thus force the EssentialDifficulty to be duplicated by each user, increasing the AccidentalDifficulty with each duplication.  Sometimes you can extract this AccidentalDifficulty into a library or helper OnceAndOnlyOnce.  Sometimes you cannot.  If you cannot, your language tool may be SimplySimplistic itself, subject to the MissingFeatureSmell.

In reference to FutureOfProgrammingLanguages, the best your languages and tools can do is become 'unobtrusive', not requiring you to perform any of this extra labor beyond saying what you need done and elaborating on what it means to do what you said needed done (either declaratively or procedurally).  The trick, for productivity and avoiding AccidentalDifficulty, is supporting this and simultaneously supporting the required NonFunctionalRequirements and UserAntiStories.

So perhaps the way to judge languages in terms of AccidentalDifficulty is in terms of:
* Inability to refactor encountered FunctionalRequirements (saying what to do, elaborating how to do it) to be OnceAndOnlyOnce in a sharable solution without leaking implementation details.  
* Inability to do either of the above while still meeting NonFunctionalRequirements (performance, security, mobility, communications and multi-lingual access, realtime, time-to-market/use, etc.)  

Since a language's ability to meet these NFRs tends to be measured 'relative' to other languages '''and''' the desire to meet them tends to be 'competitive' with other products in the same domain, it isn't possible to classify AccidentalDifficulty on an absolute scale, but only comparatively between (language x domain) pairs.  E.g. the AccidentalDifficulty introduced by VisualBasic for business forms (low rate of change, low object count, high latency acceptable) is considerably less than for producing multiplayer videogames (competitive high rate of change (for more interaction), competitive high object count, latency requirements, graceful degradation requirements, security issues for memory access in competitive play, etc.), even if both desire multi-language support and fast time-to-market/use.

All TuringComplete languages are equivalent modulo AccidentalDifficulty.  Therefore, AccidentalDifficulty, of the two forms above, is the only thing that matters when objectively comparing GeneralPurposeProgrammingLanguage''''''s.

----
IMHO, AccidentalDifficulty is the EssentialDifficulty of programming itself. -- NatPryce
----
See AccidentalComplexity, EssentialComplexity

CategoryJargon