Accidental Difficulty
Accidental DifficultyFrom 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:
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
EditText of this page
(last edited September 2, 2008)
or FindPage with title or text search