Tragically I was an only twin

subtitled The Complete Peter Cook is an excellent book by (isbn 0-09-944325-2). As usual I'm going to quote from a few pages:

Builders of Xanadu (Saturday Live, Channel 4, 1986)

...
John Bird: Got the job then?
Peter Cook: Yes, got the job.
John Bird: Big one?
Peter Cook: Well, fairly big. He's got very grandiose in his old age, Kubla has.
John Bird: Well what does he want? An extension?
Peter Cook: No, no. More than that. He wants a pleasure dome.
John Bird: Nice. What sort of pleasure dome did he have in mind?
Peter Cook: Well, he was a bit vague about it. He rambled on a bit. The only adjective I got from him was 'stately'. In fact, that's what he decreed.
John Bird: Oh, he's decreeing things now then, is he?
Peter Cook: Certainly. No pissing about with planning permission for Kubla. If he wants a stately pleasure dome, wallop! He decrees it.
John Bird: Yes, well why not?
Peter Cook: Why not, at his age?
John Bird: Did you bung him an estimate, then?
Peter Cook: No, it's a bit tricky, you see.
John Bird: What's the problem? A pleasure dome's straightforward enough. I don't know about this 'stately' though. What's this 'stately'? That's new to me. What's that? Plants? Hammocks? Not structural, is it?
Peter Cook: No, it's not structural, 'stately'. It's more of an ambience sort of area.
John Bird: Well then, we'll just budget for a regular pleasure dome, and see if we can pick up some stately trimmings down the market.
...
Peter Cook: ... Part of his decree, vis-à-vis the stately pleasure dome, is he has this bloody sacred river Alph running through the structure.
John Bird: A sacred river?
Peter Cook: Running right through the structure. He specified that.
John Bird: We'll need a plumber then. I can have Ronnie bodge up a river for you and we can bung up a sign saying 'Sacred River of Alph'. Something along those lines.
Peter Cook: Yes, but we've still got a problem with his specifications.
John Bird: What's that, then?
Peter Cook: These caverns he wants.
...
Peter Cook: ... with these caverns, you see, he's specified, here, on the docket there, 'measureless to man'.
John Bird: Measureless? He wants caverns you can't measure?
Peter Cook: Yes.
...

The evolution of useful things

is an excellent book by Henry Petroski (isbn 0-679-74039-2). As usual I'm going to quote from a few pages:

Can any single theory explain the shape of a Western saw, which cuts on the push stroke, as readily as an Eastern one, which cuts on the pull?

A French book of advice to students recognised the implicit threat involved in using a weapon at the table, and instructed its readers to place the sharp edge of their knife facing towards themselves… Such actions, coupled with the growing widespread use of forks, gave the table knife its now familiar blunt-tipped blade.

Round chopsticks would tend to twist in the fingers and roll off the table, and so squaring one end eliminated two annoyances in what is certainly a brilliant design.

The stories associated with knives, forks, and spoons also illustrate well how interrelated are technology and culture generally.

Luxury, rather than necessity, is the mother of invention.

The very properties of the material that make it possible to be shaped into a useful object also limit its use.

Engineering is invention institutionalised, and engineers engaged in design are inventors who are daily looking for ways to overcome the limitations of what already works.

It is not the form follows function but, rather, that the form of one thing follows from the failure of another thing to function as we would like.

When sewn into a garment, a piece of thread can be thought of as a continuous and flexible ghost of a needle.

It is 3M's policy (and that of other enlightened companies) to allow its engineers to spend a certain percentage of their work time on projects of their own choosing, a practice known as "bootlegging".

my kindle book-case

Here's a photo of the kindle I bought myself for Xmas.



When I bought my kindle I forgot to get a case to protect it. I searched around on a few sites looking for a case but didn't find anything I particularly liked. Before I knew it, it was time to head off to the awesome Agile Coach Camp Norway 2012. I wanted to take my kindle but needed a case to protect it. It was too late too order a case via the internet. But I had an idea. I could use a book! A regular old-fashioned hardback book.



I simply cut out a kindle-sized panel from the middle of about 100 pages and then glued the holed pages all together:



Viola, I have a case for my kindle. A book-case you might say.



I showed off my new book-case at the coach camp. It was a hit. At dinner one evening Marc Johnson mentioned he too has a kindle and loves it but misses the social aspect of a real book. The simple fact that most real books display the book's title on its front cover. People can see what you're reading. I sat next to a really interesting man on a plane once. He noticed I was reading Jerry Weinberg's Quality Software Management, vol 2, First-Order Measurement and asked me about it. We chatted away the whole flight.

My kindle book-case allows me to regain this missing social aspect. I can simply print the cover the publishers use for the real book and stick it to the front. So now I have something close to my ideal kindle case. It just needs a clear front cover sleeve so I can easily slide a cover in. And some kind of clasp. As a final bonus, I can pay homage to one of my favourite films:

Managing the design factory

is an excellent book by Don Reinersten (isbn o-684-83991-1). This is the second snippet entry for this book (here's the first). It continues my current theme of preferring to re-read a good book many times. As usual I'm going to quote from a few pages:

Whenever we see an intense need for communications it is typically a sign that the system has been incorrectly partitioned.

A complex system can often be built faster when there are stable steps along the way. This is what Nobel laureate Herbert Simon called "stable intermediate forms" in his book The Sciences of Artificial.

We cannot predict the behaviour of a system simply by understanding the behaviour of its components.

There are more possible interactions in a system of 150 components than there are atoms in the universe.

The act of partioning the system is extremely important, because it creates interfaces… these interfaces are both the primary source of value within a system and the primary source of complexity.

The nonlinear behaviour of queueing systems will amplify variability within the system.

We get into an interesting death spiral when we overload our development process. Overloads cause queues; queues, being nonlinear, raise the variability of our process, and variability raises the size of queues.

The weak cross-functional communication of the functional form sacrifices our other economic objectives.

In life, we design most processes for repetitive activities because a process is a way of preserving learning that occurs when doing an activity. … We need to find some way to preserve what we have learned without discouraging people from doing new things.

We get large queues whenever we have large batch transfers in the process.

There is a strong interaction between the design of our organisation structure, our architecture, and our development process.

The nature and art of workmanship

is an excellent book by David Pye (isbn 1-871569-76-1). As usual I'm going to quote from a few pages:

Design is what, for practical purposes, can be conveyed in words and by a drawing: workmanship is what, for practical purposes, can not.

The essential idea is that the quality of the result is continually at risk during the process of making.

The care counts for more than the judgement.

Much of what is ordinarily called skill is simply knowledge.

There is a strong incentive to design only in terms of shapes which are easy to communicate.

No two leaves of the same tree are precisely alike, each is individual: yet every one of them conforms to a recognizable pattern characteristic of the species.

Design - the music of design - depends on the relationships between distinguishable and separable features of things.

It [workmanship] takes over where design stops.

You must not torture your material.

We can have no direct rapport with the nature of any material, but have to judge what it is by looking at the surface. We can never see the thing, the material itself, but only the surface, which our vision, unlike X-rays, will not penetrate.

Freedom from command and control

is an excellent book by John Seddon (isbn 978-0-9546183-0-8). As usual I'm going to quote from a few pages:

You cannot 'motivate' someone… You can provide conditions in which employees are more likely to be motivated or demotivated, but it is a conceit to believe that managers can motivate people.

There are two jobs: job one to serve the customer and job two to improve the work.

If design is separated from process, work becomes a prescription.

Deming often asserted that knowledge should not be thought of as experience.

The value of knowledge is its use not its collection.

Leadership , in my view, is about influencing.

Some followers of Deming are unhappy with this adaptation [Check,Plan,Do] of his cycle. I believe Deming wrote about 'plan-do-check-act' on the assumption that managers who started at 'plan' were already systems thinkers. He saw 'plan' as 'have an idea based on what you "know"'; 'do' was followed by 'check' to see if the idea was right; finally 'act' meant 'put it in the line'. His model was built on manufacturing, where changes were tested off-line.

Without doubt the most important system condition affecting performance is measurement. It goes hand in hand with command-and-control hierarchical structure.

The first-level manager works with people on the work, not on the people.

Consultants who see culture change as something distinct from the work and, as a corollary, something that can be the subject of an intervention, miss the point. When you change the way work is designed and managed, and make those who do the work the central part of the intervention, the culture changes dramatically as a consequence.

The Pragmatic Programmer

is an excellent book by Andrew Hunt and Dave Thomas (isbn 0-201-61622-X). As usual I'm going to quote from a few pages:

A very simple but particularly effective technique for finding the cause of a problem is simply to explain it to someone else.

Fred doesn't know why the code is failing because he didn't know why it worked in the first place.

Chips are designed to be tested.

Design to Test.

Abstractions live longer than details.

Some things are better done than described.

Don't give in to the false authority of a method.

Test Early. Test Often. Test Automatically.

Organize around functionality, not job functions.

When woodworkers begin a project, they cut the longest pieces first, then cut the smaller pieces out of the remaining wood.

The Law of Demeter for functions states that any method of an object should call only methods belonging to: itself, any parameters that were passed in to the method, any objects it creates, and directly held component objects.

extreme Programming explained

is an excellent book by Kent Beck (isbn 0-201-61641-6). As usual I'm going to quote from a few pages:

Without courage, XP just simply doesn't work.

Communication supports courage because it opens the possibility for more high-risk, high-reward experiments… Simplicity supports courage because you can afford to be much more courageous with a simple system… Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).

Pair programming works for XP because it encourages communication… In my experience, pair programming is more productive than dividing the work between two programmers and then integrating the results.

If people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practises, particularly under pressure.

There are times when problems simply can't be solved by the emergent brilliance of the team, encouraged by a loving and watchful manager. At times like this, the XP manager must be comfortable stepping in, making decisions - even unpopular ones - and seeing the consequences through to the end.

XP is a communal software development discipline.

The best environment is one of mutual trust.

Under stress, people revert to earlier behaviour, no matter how badly that behaviour has worked in the past.

Today's design should be done today and tomorrow's design should be done tomorrow.

Nerds aren't generally good at talking.

When you say one thing and do another, bad things happen. This book [Gerald Weinberg, Quality Software Management: Volume 4(sic), Congruent Action] talks about how to be congruent yourself, how to recognise incongruence in others, and what to do about it.

97 things every programmer should know

is an excellent book edited by Kevlin Henney (isbn 978-0-596-80948-5). As usual I'm going to quote from a few pages:

Pay off technical debt as soon as possible. It would be imprudent to do otherwise. Seb Rose

Users don't think like programmers. Giles Colborne

Comment what the code cannot say, not simply what it does not say. Kevlin Henney

Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice. Jon Jagger

the Golden Rule of API Design: It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. Michael Feathers

Professional programming is usually not like running hard for a few kilometres, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. Olve Maudal

What are you working on right now? Is it all needed? Pete Goodliffe

By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Johannes Brodwall

An estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something… A target is a statement of a desirable business objective… A commitment is a promise to deliver specified functionality at a certain level of quality by a certain date or event… Giovanni Asproni

If your project is apparently on track, and one week later it's six months late, you have problems - the biggest of which is probably not that it's six months late, but the invisibility force fields powerful enough to hide six months of lateness! Lack of visible progress is synonymous with lack of progress. Jon Jagger

Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard. Burt Hufnagel

The Singleton Pattern… What's not to like about this classic design pattern? Quite a lot, it turns out. Sam Saariste

The ACM Turing Award Lectures

is an excellent book (isbn 0-201-54885-2). As usual I'm going to quote from a few pages:

The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. [Edsger Dijkstra]

If we go back to Latin roots, we find ars, artis meaning "skill." It is perhaps significant that the corresponding Greek word was Τέχνη, the root of both "technology" and "technique". [Donald Knuth]

The assignment statement is the von Neumann bottleneck of programming languages. [John Backus]

I find a certain technique most helpful in expanding my own capabilities. After solving a challenging problem, I solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for. Then I look for a general rule for attacking similar problems in the most efficient way the first time. Often, such a rule is of permanent value…
To sum up, my message to the serious programmer is: spend a part of your working day examining and refining your own methods. [Robert Floyd]

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. [C.A.R. Hoare]

UNIX is a simple coherent system that pushes a few good ideas and models to the limit. [Dennis Ritchie] I am a programmer. I write programs. [Ken Thompson]

To parody our current methods of teaching programming, we give beginners a grammar and a dictionary and tell them that they are now great writers. We seldom, if ever, given them any serious training in style… Like writing, programming is a difficult and complex art. [R.W. Hamming]

There are many ways to formulate things and it is risky to become too attached to one particular form or law and come to believe that it is the real basic principle. [Marvin Minsky]

To state a problem is to designate (1) a test for a class of symbol structures (solutions of the problem), and (2) a generator of symbol structures (potential solutions). To solve a problem is to generate a structure, using (2), that satisfies the test of (1). [Allen Newell and Herbert Simon]

The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important. [Kenneth Iverson]

A little book of f-LAWS

is an excellent book edited by Russell Ackoff and Herbert Addison (isbn 0-9550081-1-5). As usual I'm going to quote from a few pages:

The best organisations aim to remove the expectation of compliance and eliminate the fear of getting things wrong.

Doing something right can only confirm what one already knows or believes; one cannot learn from it. However, one can learn from making mistakes, by identifying and correcting them.

Organizations fail more often because of what they have not done than because of what they have done.

The opportunity for real and useful learning comes in the face of adversity.

The people who achieve real mastery at something know what it is that makes them so good.

The best managers are genuinely interested in finding out what other people think and have superb listening skills.

Consumer involvement in product/service design almost always gets creative results.

General principles of systems design

is an excellent book edited by Jerry Weinberg (isbn 0-932633-07-2). As usual I'm going to quote from a few pages:

It's not the appearance that's the essence of their structure, it's their endurance. Structure is that which stands, which remains, which is unchanged, regardless of its physical properties.

No answer can be both precise and general at the same time.

Aggregation gives protection against the unknown; specialization against the known; and the use of each sacrifices some opportunity to use the other.

The concept of structure... derives from the concept of stability, and not vice versa.

Any representation of a system tends to make certain insights easier at the expense of making others harder.

Failing to yield is the only clue we have to the existence of structure... we can only understand permanence through attempts to change it.

When a system has to deal simultaneously with two threats, protection against one will increase vulnerability to the other.

This conception of the relationship between structure and behaviour is utterly contrary to the most widely held view - namely that structure determines behaviour.

The system responds more slowly in order to respond more surely.

The regulator must be active so that other parts may be passive.

Regulation is invisible - when it works.

Complexity is a relationship between system and observer.

Not only do birds regulate the insect population, but the insects return the favour for the birds.

There is a tendency for complexity in models to rise as the time between sensing and acting grows.

Rethinking systems analysis and design

is an excellent book by Jerry Weinberg (isbn 0-932633-08-0). As usual I'm going to quote from a few pages:

We don't need another "movement" just now - unless it is something analogous to a bowel movement - something to flush our system clean of waste material that we've accumulated over the years.

When dealing with the unknown, it appears to be better to handle one situation at a time, examine the results obtained, and then prepare a plan for the next situation.

How to master oneself? The Eastern philosophers have always understood, but it seems the most arduous lesson for us westerners. One masters oneself by giving up the attempt. By approaching an interview with the attitude that one cannot be absolutely in control, one attains the utmost possible control.

One of the greatest divisions [of human thought] is between static and dynamic schemes, between thing and process, between noun and verb.

The architect without the stonemason is not designing cathedrals, but castles in the air.

The way things are is always fighting with the way things might be.

The rough sketch has several advantages over the precise drawing: it represents less investment in time, so we're not afraid to throw it away and try something else; its very roughness conveys important information about where we are in the design process.

The ability to decide when to stop is a feature not a failure.

90% of aggravation in programming projects comes at the end.

Notes on the synthesis of form

is an excellent book by Christopher Alexander (isbn 0-674-62751-2). As usual I'm going to quote from a few pages:

Poincaré once said: "Sociologists discuss sociological methods; physicists discuss physics." I love this statement. Study of method by itself is always barren.

Culture is changing faster than it has ever changed before...what once took many generations of gradual development is now attempted by a single individual.

Modern mathematics deals at least as much with questions of order and relation as with questions of magnitude.

If the world were totally regular and homogeneous, there would be forces, and no forms. Everything would be amorphous. But an irregular world tries to compensate for its own irregularities by fitting itself to them, and thereby takes on form. D'Arcy Thompson has even called form the "diagram of forces" for the irregularities.

No complex adaptive system will succeed in adapting in a reasonable amount of time unless the adaptation can proceed subsystem by subsystem, each subsystem relatively independent of the others.

We define a concept in extension when we specify all the elements of the class it refers to. And we define a concept in intension when we try to explain its meaning analytically in terms of other concepts at the same level.

Design is by nature imaginative and intuitive.

Every form can be described in two ways: from the point of view of what it is, and from the point of view of what it does.

It is the culmination of the designer's task to make every diagram both a pattern and a unit. As a unit it will fit into the hierarchy of larger components that fall above it; as a pattern it will specify the hierarchy of smaller components which it itself is made of.

What is it about the internal structure of any problem that makes it hard to solve? In nine cases out of ten, we cannot solve it, because we cannot grasp it.

Managing the design factory

is an excellent book by Don Reinertsen (isbn 0-684-83991-1). As usual I'm going to quote from a few pages:

Best practices are only "best" in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a "best practice" into a stupid approach.

We must constantly remember that the simplification [of the abstraction] is a veil between us and the reality of the process.

Manufacturing is an inherently repetitive process and therefore more likely to produce learning than a non-repetitive process, like product development.

In the design process we can only add value when we do something differently. If we change nothing, then we add no value.

We will see much more variability in the design process than we see in repetitive manufacturing process. This variability is an indicator that we are doing something new in the design process, and thus that we are adding value.

Risk and the variability associated with it, are inherent and desirable characteristics of design processes. They are at the heart of a design process's capacity to generate information.

The design factory needs variability, so it needs tools that allow us to coexist with variability.

When you dig below the surface you discover that most change programs are motivated by two forces: imitation and obedience.

Events that are less probable contain more information.

Our testing processes need to have an adequate failure rate to generate sufficient information.

Each iteration starts on the base of the quality of the previous pass.

A process is a way of preserving learning that occurs when doing an activity.

The Humble Programmer

by Edsger W. Dijkstra, 1972 ACM Turing Award Lecture:

We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad of cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worthwhile to point out that the purpose of abstraction is not to be vague, but to create a new semantic field in which one can be absolutely precise.

The tools we are trying to use and the language or notation we are using to express or record our thought are the major factors determining that we can think or express them at all!

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility.

Programming will remain very difficult.

The best way to learn to live with our limitation is to know them.

In computer programming our basic building block has an associated time grain of less than a microsecond, but a program may take hours of computation time. I do not know of any other technology covering a ratio of 10^10 or more.

This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation; it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

Patterns of Software

is the title of a truly excellent book by Richard Gabriel. I reread this every year or so. Each time it speaks to me with new depth and wisdom. As usual I'm going to quote from a few pages:

My overall bias is that technology science, engineering and company organization are all secondary to the people and human concerns in the endeavor.

Compression is that characteristic of a piece of language in which each word assumes many meanings and derives its meaning from the context.

What [D'Arcy] Thompson insisted on was that every form is basically the end result of a certain growth process.

The process of software construction is the single most important determining factor in software quality.

Methodologists who insist of separating analysis and design from coding are missing the essential features of design: The design is in the code, not in a document or in a diagram.

Poincaré; once said: "Sociologists discuss sociological methods [not sociology]; physicists discuss physics [not physics methods]." I love this statement. Study of method by itself is always barren.

Study software, not software methods.

If we hope to make buildings in which the rooms and buildings feel harmonious; we too, must make sure that the structure is correct down to ¹/₈^th of an inch.

To get wholeness, you must try instead to strive for this kind of perfection, where things that don't matter are left rough and unimportant, and the things that really matter are given deep attention.

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 granularity it looks the same; it is a system.

In the modern era, we have come to favor simplicity over complexity, perfection over imperfection, symmetry over asymmetry, planning over piecemeal growth, and design awards over habitability. Yet if we look at the art we love and the music, the buildings, towns, and houses, the ones we like have the quality without a name, not the deathlike morphology of clean design.

The Mythical Man Month

is the title of an excellent book by Fred Brooks. It's well worth rereading every year or so. As usual I'm going to quote from a few pages:

The accumulation of simultaneous and interacting factors brings slower and slower motion.

Human beings are not accustomed to being perfect and few areas of human activity demand it.

Our estimating techniques fallaciously confuse effort with progress.

No part of the schedule are so thoroughly affected by sequential constraints as component debugging and system test.

Take no small slips... Trim the task.

I will contend that conceptual integrity is the most important consideration in system design.

...the total creative effort involves three distinct phases: architecture, implementation, and realization. It turns out that these can in fact be begun in parallel and proceed simultaneously.

Any software system should be grown by incremental improvement... Nothing in the past decade has so radically changed my own practice, or its effectiveness.

Unless we teach people how to design, the languages matter very little.

The Mythical Man Month is only incidentally about software but primarily about how people in teams make things.

How Buildings Learn: Chapter 2 - Shearing Layers

How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.

Building on the theme of time again he quotes Frank Duffy (ex president of the Royal Institute of British Architects) "Our basic argument is that there isn't such a thing as a building. A building properly conceived is several layers of longevity of built components".

Some layers live longer than other layers.

Some layers are more stable than other layers.

Layers change at differing rates.

The rates of change over time define the layers as clearly as the individual physical changes.

Brand extends Duffy's four S's shearing classification to six S's: Site, Structure, Skin, Services, Space plan, Stuff.

Quoting Duffy again "The unit of analysis for us isn't the building, it's the use of the building through time. Time is the essence of the real design problem."

Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.

Hummingbirds and flowers are quick, redwood trees slow, and whole redwood forests even slower. Most interaction is within the same pace level.

The dynamics of the system will be dominated by the slow components, with the rapid components simply following along. Slow constrains quick; slow controls quick.

Echoing the quote from Churchill, that the building learns from it occupants and they learn from it, he provides a fascinating insight - "In classical Greece and Rome domus meant house in an expanded sense: People and their dwellings were indistinguishable: domus (as in Romanes eunt domus - Life of Brian) referred not only to the walls but also to the people within them."

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