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 OperatingSystems 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
GeneralPurposeProgrammingLanguages.
IMHO,
AccidentalDifficulty is the
EssentialDifficulty of programming itself. --
NatPryce
See
AccidentalComplexity,
EssentialComplexity
CategoryJargon