Principle Of Beneficent Difficulty
Principle Of Beneficent Difficulty[One of the SelectingaMethodology points...]
See: http://computing.unn.ac.uk/staff/cgpv1/downloadables/CD3005/contents.pdf -- (page 25 of the Acrobat document, page 109 printed) -- which says, among other things...
12.7. The Principle of Beneficent Difficulty
"Difficulties, explicitly characterised and diagnosed, are the medium in which a method captures its central insights into a problem. A method without limitations, whose development steps are never impossible to complete, whose stages diagnose and recognise no difficulty, must be very bad indeed. This is because such a method is saying one of two things to you:
[All of chapter 12 in the above link is a good read: It gives advice on the selection and combination of methods to meet the needs of your project.]
If it's too easy, it's probably not helping much.
Michael Jackson sets forth this principle in SoftwareRequirementsAndSpecifications, and relates it to the process of assessing whether a problem frame fits a target problem well or not.
In applying a problem frame to a problem, a perfect and easy fit is unlikely for any real world problem because of the variability found in the real world. Therefore, an easy fit implies a sloppy fit, and one which won't yield much of use on the solution side.
Pushing for a tighter fit usually reveals areas of misfit, and signals difficulty in the analysis. Engaging the difficulty is seen as the key in making problem frame analysis work, as the misfit areas isolate the unsolved portions of the problem. Ignoring them is "easy", but ineffectual.
To add some spin: Some methods are easy to do, and can't fail, but the system they produce is brittle, because as the business changes, large changes are needed to their models and code.
Example: FunctionalDecomposition (from say event partitioned DataFlowDiagram) -- They're easy to do. Any process can be diagrammed and implemented. But changes in the way the business views itself can cause dramatic changes to the DataFlowDiagram, forcing a rewrite of code in many parts of the system.
So there can be a "hidden hurt" that's not discovered until after you deliver the system.
I can't decide whether this principle was made up by a slavedriver, a classic Protestant (with no insult intended to real Protestants), or someone too dull to find the right tool. Things that work well don't hurt. One gets tired ... but the work isn't hard. --RonJeffries
See "The PrincipleOfDispassionateMethodology." ;->
On the other hand, I doubt this principe is about hurting. Recognizing difficulties and tackling them doesn't have to hurt, does it ? And the bits about "all problems are easily solved" rings true to me.
It's not the thing working that's the difficulty, it's the search for the right thing, or the fine tuning of the almost right thing until it's right. It probably doesn't matter who made the principle up, as long as it "fits". And if it does fit, then it helps motivate when things do seem hard. Works for me, anyway. But then, I'm a slave-driving classic Methodist with buck teeth.
See HardWork
EditText of this page
(last edited November 26, 2014)
or FindPage with title or text search