Goldilocks Solution

If I am going to shoot off my mouth about educational philosophy, I'd better back it up with some substance. Here is one of the LearningPatterns I use all the time, now that I've made it explicit. Try it and share your experience here. -- KentBeck

How do you learn to navigate along a continuum?

Someone says to you, "Methods in an object program should be shorter than functions in a procedural program." How are you going to find out how short is short? You could rely on an expert's arbitrary number. You could rely on a metric tool to tell you.

Neither of these really help. What you want is a feel for how big methods should be. But you're already nervous about this object stuff, you don't really have enough time, ...

So here's what you do: you write a little program, big enough that it isn't trivial but small enough that you can finish it in a day. First you write your program with the methods too big - make them as big as you possibly can. Then you write your program with the methods too small - one line each. Then you write the program with the methods somewhere in the middle.

The technique works any time you are faced with a new continuum. The trick in situations like this is getting started. When faced with a new continuum, we tend to freeze, which isn't a very helpful learning strategy. Then we tend to pick one point along the continuum and move very slowly from it, if at all.

No. First we have to find the boundaries. Then we can find our comfort zone within those boundaries. And we have to get over being stuck first. Making failure part of the goal helps with this.

Do the activity three times: once at one end of the continuum, once at the other end of the continuum, once in the middle.



In the children's story, "Goldilocks and the Three Bears," Goldilocks always makes the "middle" of three choices. Like, in beds, "'this one's too hard; this one's too soft; this one's just right,' so she slept in it." (Same for hot/cold porridge, and other things she found in the bears' house.) But she makes the "middle" choice only after having sampled the extremes (as in Kent's LearningPattern? above).

Her choice is in the middle on one axis (taste, temperature, hardness, height in various versions of the story) but at one end on another axis (the smallest in every version of the story).

[See also "Politically Correct, the Ultimate Storybook : Politically Correct Bedtime Stories, Once upon a More Enlightened Time, Political Correct Holiday stories" ISBN 0765108674 , for a different perspective on these stories.]

More generally, there are lots of optimization problems involving an arrangement of opposing forces where benefit rises at first, then falls, as a variable or variables are changed. In other words, there is a point in the parameter space "somewhere in the middle" that maximizes the benefit. This optimum point is often called a GoldilocksSolution.


On the other hand... Do we really want to try it out in cases like the second test above - i.e. hiking in the Alps with a newborn until we encounter "failure"? Aren't there cases where the cost of failure would preclude experiments?

The parallel to testing is striking to me. I like to test at the extremes of a range and once in the middle. Another parallel.. FrankLloydWright once said something similar about design. Something like "Take care of the corners and the walls will take care of themselves." This seems to be a way of filling out a structure, be it a room or our knowledge or experience. -- MichaelFeathers

This is a common misconception. Testing the middle of the range is actually redundant. If there is a bug reproducible by such test, the other two tests will always find it. Therefore - test the boundaries only.

[3rd voice] Even when testing for linearity? If using a piecewise linear approximation, the boundary conditions (from a code perspective) are usually the breakpoints in the approximation. However, the failure cases are between the breakpoints, where the error is most likely to bring the approximation out of spec. Be careful with AlwaysAndNever.

This is not really an exception. By definition, a linearity test is a test to determine what the BoundaryConditions? are; it is not a test of the BoundaryConditions? but a meta-test to determine what cases need to be tested. The problem is that too often such a test is not made, and as a result invalid assumptions are made as to where the BoundaryConditions? lie. OTOH, such meta-testing itself is subject to meta-meta-testing, and those tests to meta-meta-meta-testing, which eventually spirals into the VonNeumannCatastrophe.

A neat analogy, well put. I like the implicit logic that some one (daddy bear) likes the big program and someone else likes the little program that is only 90% correct (that's me I guess, a lot of the time).

A small quibble... you usually can't optimize one thing in two directions at once. You can go for the fewest number of classes, or the fewest number of methods, you can attach a weight to each class and method and make the sum as small as possible, or work on a complex formula.

-- DickBotting

Remember though, we're not talking about minimizing the number of methods and/or classes... it's more along the lines of method length... I'd rather have five classes with twenty 5-line methods each than one class with five 50-line methods. -- WilliamUnderwood

The reason you'd like that might have to do with expressing ideas. That's the notion just ahead of minimizing in the third, just right, program.

There is a Swedish word for "just right" (that it the closest thing in English that matches this word) and that word is "LaGom?". -- MathiasDahl

See FindingTheMiddleWay for an application to CategoryLifeStrategies.

See Also: MorePainMoreGainSolution, LessIsBetterSolution, BinarySolution, SpecializationSweetSpot, HegelianDialectic, DoTheSimplestThingThatCouldPossiblyWork

Is this a learning pattern? It sounds more like an optimization strategy. -- HelmutLeitner


View edit of November 11, 2013 or FindPage with title or text search