The Hidden Dimension

Is an excellent book by Edward T. Hall. As usual I'm going to quote from a few pages:

One of the most important functions of territoriality is proper spacing, which protects against over-exploitation of that part of the environment on which a species depends for its living.

As numbers of animals in a given area increase, stress builds up until it triggers an endocrine reaction that acts to collapse the population.

Man's evolution has been marked by the development of the "distance receptors" - sight and hearing...

There is a general relationship between the evolutionary age of the receptor system and the amount and quality of information it conveys to the central nervous system. The tactile, or touch, systems are as old as life itself.

As Freud and his followers observed, our own culture tends to stress that which can be controlled and to deny that which cannot.

All works of art are created on a certain scale. Altering the size alters everything.

The present internal layout of the house... is quite recent. As Philippe Aries points out in Centuries of Childhood, rooms had no fixed functions in European houses until the eighteenth century.

Many of my European subjects observed that in Europe human relationships are important whereas in the United States the schedule is important.

The study of Japanese spaces illustrates their habit of leading the individual to a spot where he can discover something for himself.

Planning and renewal must not be separated; instead, renewal must be an integral part of planning.

Like the link between cancer and smoking, the cumulative effects of crowding are usually not experienced until the damage has been done.

the (de)composition fallacy

You've probably heard the saying "the whole is greater than the sum of the parts". You can think about this law in various ways. For example, if you remove the brain from a man you no longer have a man minus a brain. You have two dead things. A brain is more than just a "part" of a man. A part has relationships to a whole that contribute to the essential wholeness of the whole.

Another way is at a much simpler level - where all the parts are of the same type aggregating together over time. Time patterns them. Human beings are pretty poor at seeing effects over time. We tend to think things are more permanent than they are. We think that the way things are now is how they've always been and how they'll continue to be. I recall showing my children some old Victorian pennies and telling them that's what pennies used to look like. They didn't believe me! Before street lighting it was apparently very common in England to have two sleeps a day. The short one after a midday meal was called the "small sleep". The time we eat our main meal has changed. Eating several courses at a meal is a relatively recent phenomenon. The cutlery we eat with has changed. And what we wear. Before the 17th century your left and right shoe (if you had shoes at all) were the same and were called "straights".

But things do change, and this matters because

Things that don't matter in isolation often matter in composition.

Suppose you compile some code and you get a few warnings. Do these warnings matter? You might think not, since there are only a few, but they do. Tomorrow you'll be writing some more code, and the day after that some more too, and so will your colleagues. After six months those few warnings have turned into 3000 warnings. That's the composition fallacy.

3000 warnings is a big problem for at least two reasons. But the two reasons I'm thinking of are really the same reason. Let me explain.

The first reason is that if you've got 3000 warnings then any new warnings aren't even noticed in the comparative vastness of the existing 3000. You've become completely desensitized to warnings. The number of warnings inexorably grows but no one notices - you've just got "a lot of warnings" that is always "a lot of warnings".

The second reason is the same reason but in reverse.

Suppose you see what you couldn't see before - that a lot of warnings is a composition problem - and you try to do something about it. You've now got to work hard learning how to do something you don't know how to do - namely how to write code without warnings. That takes effort. And what do you get for all your effort? Almost nothing it seems! The number of warnings goes down a tiny bit but there are so many warnings you've hardly made any difference at all. A lot of warnings remains a lot of warnings.

One thing you can do in this situation is to stop reporting the total number of warnings and switch to reporting only the number of warnings either added or removed. This is an example of switching from a static measure (the number of warnings is now 2981) to a more dynamic measure (in the last 24 hours the number of warnings has gone down by 19).

progressive fly fishing for salmon

is an excellent book by Alexander Baird Keachie (isbn 1-86126-048-2). As usual I'm going to quote from a few pages:

If you want the maximum pleasure from the sport, be patient, because the more difficult the trade, the longer is the apprenticeship.

On entering freshwater, 90 percent of the retinas [of Coho salmon] are dominated by porphyropsin, or red visual pigment. ... Initial preliminary microspectrophotometric testing of the Atlantic salmon has shown that their retina colour pigmentation closely follow that of the Coho.

In short, when the water level starts falling, or if the water temperature increases, reduce your size of fly. Conversely if the water height increases, or the water temperature takes a downward turn increase your fly size accordingly.

Wood discovered from his fishing that the speed of the fly in relation to its size was of paramount importance. For instance, he found that the only effective way to fish a small fly was to present it at a speed which would be natural to a creature of similar size.

In my opinion most anglers change their flies too often, generally because they lose faith in it. Moreover, when they change flies it is normally for one of a different colour, and not size, and I believe that this is a great mistake.

In fact he [A.H.E. Wood] did not think pattern made much difference, but considered size of much greater importance. J.A. Hutton asked him why he only ever used two flies, a Blue Charm and a Silver Blue. Wood replied that he didn't care which he used. J.A. Hutton then asked him why then he did not use a March Brown, a fly not commonly used at the time for salmon fishing. To this Wood replied that he would use nothing else for the rest of the season, which he did - and took the same number of fish as he would normally have expected to catch during a season.

The main advantage which tube flies have over other flies is that they can be 'queued'; this means you can create a fly of any length, colour, and weight.

Whatever practices you follow when making the 'D' loop, all movements should be continuous and smooth: these will load a rod progressively, while jerky uneven actions cause irregular loading.

The principles of product development flow

is an excellent book by Donald Reinersten (isbn 978-1-935401-00-1). As usual I'm going to quote from a few pages:

Operating a product development process near full utilisation is an economic disaster.

When we emphasise flow, we focus on queues rather than timelines.

Almost any specialist can become a queue.

We grow queues much faster than we can shrink them.

When queues are large, it is very hard to create urgency.

Queues amplify variability. Moving from 75 to 95% utilisation increases variability by 25 times.

Sequential phase-gate processes have inherently large batch transfers.

Large batches encourage even larger batches.

Reducing batch size is usually the single most effective way to reduce queues.

Companies inevitably feel they can computerise this whiteboard, however, they almost always create a more elegant but less useful system.

The speed of feedback is at least two orders of magnitude more important to product developers than manufacturers.

The human effect of fast feedback loops are regenerative. Fast feedback gives people a sense of control; they use it, see results, and this further reinforces their sense of control.

Homeostasis is the tendency of a system to maintain its current state.

In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.

Opportunities get smaller with time, and obstacles get larger.

The scarcest resource is always time.

To align behaviours reward people for the work of others.

It has been said that one barbarian could defeat one Roman soldier in combat, but that 1,000 Roman soldiers could always defeat 1,000 barbarians.

The Marines, and all other elite organisations, maintain continuity in their organisational units.

We'll never survive!

One of the books for the accu charity book stall is my copy of Extreme Programming Explained by Kent Beck (1st edition).
One of the entries in its bibliography is a quote from The Princess Bride.
Buttercup and Westley are about to enter the Fire Swamp and face it's three terrors: the Flame Spurts, the Lightning Sand, and the Rodents Of Unusual Size (R.O.U.S.'s).







Buttercup says to Westley (Kent misquotes slightly here):

We'll never survive

and Westley replies:

Nonsense - you're only saying that because no one ever has.

I just love this line. And I love Kent's idea of putting a film quote in the bibliography. I love that it's in the bibliography in a section called "Attitude". I think Kent is hinting at their courage - that depending on your attitude life can be an adventure. After surviving the flame spurts Westley says to Buttercup:

Well now, that was an adventure.

And a bit further on he says:

The Fire Swap certainly does keep you on your toes.

Just before facing the R.O.U.S.'s Buttercup says:

We'll never survive - we may as well die here.

To which Westley replies:

No. No. We have already succeeded.

I love that line too. (I pretty much love every line of the film.) Again it's about attitude. As they make it out of the fire swamp Buttercup says (almost in disbelief):

We did it.

And Westley says:

Now, was that so terrible?

Attitude.
Caring about yourself.
Caring about others.
Caring about the code.

Complexity Matters

Managing complexity is not just how you connect things together but to what extent the connection mechanisms scale. In Nature the scalability of the mechanisms seems to have hard physical limits. D'Arcy Thompson [1] wrote:

In nature, the effect of scale depends not on a thing in itself but in relation to its whole environment.

Everywhere Nature works true to scale, and everything has its proper size accordingly.

In short, it often happens that of the forces in action in a system some vary as one power and some as another, of the masses, distances or other magnitudes involved; the "dimensions" remain the same in our equations of equilibrium, but the relative values alter with the scale. This is known as the "Principle of Similitude", or dynamic similarity, and it and its consequences are of great importance.

Size matters too. Even the smallest mistake can kill an animal/program. In [2] Richard Gabriel writes:

build small abstractions only

build hierarchies slowly, keeping them shallow as long as possible

buildings with the quality are not made of large modular units

we must make sure the structure is correct down to 1/8th of an inch (quoting Christopher Alexander)

Fan-in/fan-out is important complexity metric. The difference in complexity between different levels of the system should be roughly the same. This is reminiscent of fractals and what Christopher Alexander calls "centers". Again from Patterns of Software:

without large structure, the design cannot hold together - it becomes merely a jumble of isolated design elements.

The nature of a system is such that at almost any granularity it looks the same - it is a system. ... When we put together an object-oriented thing, it is a system, not a program. The difference between a program and a system is precisely the characteristic of a system having many centers or ways of approaching it - from the vantage point of any sub-system, the rest of the system is a server - whereas in a program, you generally have a single way of viewing it, usually from the top down.'

Objects are important because they make it easier to create systems rather than programs and systems can handle complexity and change better than programs.

[1] On Growth and Form. D'Arcy Thompson. Cambridge University Press. ISBN 0-521-43776-8

[2] Patterns of Software. Richard Gabriel. Oxford University Press. ISBN 0-19-5100269-X