Ridiculous Simplicity Gives Ridiculous Resources

"Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%." -- DrPaulMacCready

[Thanks to the JohnBrewersXpFaq for the reference.]


Ah, if only people believed it. I believe it, but few other people in my organization do. They'll always ask the question, How do you know it's 98% and 2%? -- JbRainsberger


A: Suppose it's 80/20. Say the ridiculously simple answer is 10x simpler, and when you blow it, you have to do it over. OK: .80/10 + .2/10 (to do the hard ones wrong the first time) + .2*1 (to do the hard ones over "the right way") = .08 + .02 + .2 = 0.30. In other words, you'll get the work done in 30% of the time -- over three times as fast. Now how many managers don't believe in the 80/20 rule? ;->

(Also, 2/3 of the remaining work you do is rework, so if only you could learn from your mistakes, it would go faster, wouldn't it? This makes "3 times faster" a pessimistic estimate. ;-)


For those who couldn't follow the math, here's another way of saying the same thing.

Scenario A: Try every problem the easy way (cost = $1.00), hoping you're right. Scenario B: Try every problem the more thorough, complex way (cost = $10), to make sure it's done right the first time.

Scenario A
	tryWithEasyCost = $1
	everyProblemRate = 100%
	doneCost = $0
	easySuccessRate = 80%
	easyFailRate = 100% - easySuccessRate = 20%
	expectedCost = tryWithEasyCost * everyProblemRate + doneCost * easySuccessRate + retryWithHardCost * easyFailRate
	= $1 * 100% + $0 * 80% + $10 * 20%
	= $3

Scenario B
	tryWithHardCost = $10
	everyProblemRate = 100%
	expectedCost = tryWithHardCost * everyProblemRate
	= $10 * 100%
	= $10

In general, if we assume the 80/20 rule, then we break even when easyCost = 80% * hardCost. So if the easy way is at least 20% cheaper, then go for it.


Without disagreeing with this (I don't), it's nevertheless interesting to note that Scenario B is simpler than Scenario A. Not more efficient, not preferable, not anything... but simpler. --CarlManaster


If the EightyTwentyRule is universally true, that 20% which didn't get done can be solved with just the 80% of the original resources. Then you can apply the same rule to the remaining part, meaning 80% of 20% gets solved with 20% of 80% of the resources. That means you solve 16% of the original problem with 16% of the original resources. The total work done now is 96% and the total remaining resources are 64%.

Apply the same 80/20 rules again and you can solve 80% of 4% (that's 3.2%) by using 20% of 64% (that's 12.8%), so 99.2% or the work can be solved by using 51.2% of the resources. You have almost half the resources left to solve less than 1% of the problem, and only by applying the 80/20 rule. -- GuillermoSchwarz


This is the RISC principle! ReducedInstructionSetComputer

It's also the idea behind ThinLocks and OptimisticLocking. Stretching it slightly, it's similar to medical triage.
Moved from RidiculousSimplicityDemandsRidiculousResources, due to a misunderstanding on the part of SamuelFalvo?

A far, far better example is ForthLanguage. Unlike BF, it's actually a real programming language, being used for real-world applications today (see http://www.forth.com/resources/appNotes/index.html). How is it simpler?

 : (   [char] ) parse 2drop ; immediate
 : \   source >in ! drop ; immediate

--SamuelFalvo?

Without a lexer, parser, or type system, writing a compiler for Forth is rediculously simple, and consumes rediculously little resources:

 32 constant bl

\ This is a functional Forth compiler, albeit a very simple one, written itself \ in Forth. This will compile to no more than a kilobyte on most 32-bit \ implementations of Forth. \ ] starts the compilation, while [ ends it. This convention follows from how \ one switches in and out of compile-mode from inside a colon-definition. \ : seven [ 3 4 + ] literal ; \ is exactly the same as: \ : seven 7 ;

: validate c@ bl xor abort" Word not in dictionary, and not a valid number!" ; : try-number 0. rot count >number drop validate ['] push-literal compile, , ; : ] begin bl word find dup 0< if drop execute ( it's an immediate word ) else if compile, ( it's a normal, every-day word ) else try-number then then again ; : [ r> drop ; immediate

Embellishing it with additional features is similarly easy. Whole industries and books are written on compilers and compiler theory. Not to diminish the value of their research, it stands to reason that if folks followed a ForthValue? system, a lot of people would be without a job (at least, in this domain).

From all this, you get a functional (as in working, not as in referentially transparent) language compiler that is small enough to run even on deep-embedded platforms, where most applications compiles to mere kilobytes of memory, is interactive, is expandable and malleable enough to support more advanced features given sufficient machine resources (e.g., don't expect an entire IDE to run on an ATmega chip, but such Forth IDEs do exist on Windows), and whose performance is often compared to C (anywhere from factor-of-two-slower to as-fast-as-optimized, depending on how much cash you spend on the compiler; either way, the range is quite admirable).

Not bad, if I do say so myself. --SamuelFalvo?

So, I suppose we can therefore conclude that ForthLanguage must not be ridiculously simple. It's just 'appropriately' simple. (NoTrueScotsman.)
See DoMoreWithLess, RidiculousSimplicityDemandsRidiculousResources
CategoryQuote

See BetterSorryThanSafe


EditText of this page (last edited July 13, 2014) or FindPage with title or text search