patterns of connection

When I read a good book I highlight passages that catch my attention. I copy a few of the highlights into a book-snippet.

This photo is of page 75 of my battered copy of The Secrets of Consulting. The yellow highlights are from the first time I read the book, the pink ones from the second time, the blue ones the fourth time. At the bottom right is one sentence outlined in pen and marked with an eight. That tells me I marked that sentence on my eighth re-read. (I've run out of new colours.)

I find it better to re-read a really good book 10 times rather than read 10 average books once each. It's the really good books that provide new insights each time I re-read them. Marking highlights in this way allows me to go back in time. What topics caught my attention in early readings? What topics in later readings? I can explore the differences. Of course, part of that newness is that I'm a different person each time I re-read. I'm older. A sentence triggers a new thought based an experience I've had since my last read. Also, I remember more of the book each time. For example I can see on my seventh re-read I marked this

The toughest problems don't come in neatly labeled packages. Or they come in packages with the wrong labels.

and I underlined the words labeled and labels because I'd consciously connected them to The Label Law (on page 64).

The name of the thing is not the thing.

Underneath that I can see I've written "The Dread Pirate Roberts". That's a connection to a scene from one of my favourite films, The Princess Bride. Westley is in the fire swamp explaining to Princess Buttercup how he has become the Dread Pirate Roberts...

Westley: I, as you know, am Roberts.

Buttercup: But how is that possible, since he's been marauding twenty years and you only left me five years ago?

Westley: I myself am often surprised at life's little quirks...

Westley: Well, Roberts had grown so rich, he wanted to retire. So he took me to his cabin and told me his secret. "I am not the Dread Pirate Roberts," he said. "My name is Ryan. I inherited the ship from the previous Dread Pirate Roberts, just as you will inherit it from me. The man I inherited it from was not the real Dread Pirate Roberts, either. His name was Cummerbund. The real Roberts has been retired fifteen years and living like a king in Patagonia." Then he explained the name was the important thing for inspiring the necessary fear. You see, no one would surrender to the Dread Pirate Westely.

John Gall (who was born in 1925), recently gave a fabulous talk called how to use conscious purpose without wrecking everything. He said:

As the years go by, the brain begins to put the dots together, to make conscious links between one experience and another, between one historical fact and another. A person begins to experience one’s entire life history as an integrated narrative.

This integrating capacity of the human brain is perhaps its most marvelous achievement. And you have to be old—usually fifty or sixty years old—to reach that point where it dawns on your conscious mind that that’s what’s going on. Unless you are already in your coffin, your mind is always a work in progress, an ongoing process of continual growth and greater differentiation, richer and more far-reaching correlations.

He chatted about how much his mind had changed during the first 40 years of his life compared to the most recent 40 years of his life. He said the latter change was far greater.
Isn't that amazing. Fantastic.
I'm looking forward to getting older!
I'm looking forward to seeing more and more patterns of connection.

driving in India

Patterns of Software by Richard Gabriel is one of my favourite books. On page 60 he quotes Christopher Alexander (who is talking about D'Arcy Thompson)

What Thompson insisted on was that every form is basically the end result of a certain growth process. ... Thompson was saying that everything is the way it is today because it is the result of a certain history - which of course includes how it got made. At the time I read this I did not really understand it very well; whereas I now realize that he is completely right.

I'll use an example to try and illustrate this idea of, as Jerry Weinberg puts it, things being the way they are because they got that way. The example is driving in India.

The most obvious thing that strikes me when I visit Bangalore or Chennai is the almost constant horn tooting. Is tooting your horn a formally taught behaviour, or is it learned behaviour I wondered. I asked some friends who live in India. They said it is not something you're taught. It is learned behaviour. I find this fascinating. It could mean that at some point in past tooting was common, but not endemic, and that for some reason or reasons it reached a tipping point and became endemic. What are those reasons? Why did they prevail? Do those reasons apply to all Indian cities or are some quieter than others? Do the reasons shed any light on whether endemic horn tooting will or won't ever go away?

A pattern I started to sense during my most recent trip is when a slow vehicle is stuck behind an even slower vehicle (a bus for example) and toots the horn as if to say "move over". The bus slowly moves over, the first vehicle passes it, and as it goes by toots twice, the first toot to say "thank" and the second toot to say "you". I never got the sense the tooting was overtly aggressive. I think drivers are tooting mostly to tell other drivers where they are. Considering the apparent chaos everyone is remarkably relaxed! The tooting has become part of a system of communication.

Naturally, once certain behaviours get a foothold, other behaviours adapt to them, helping to reinforce the co-evolving system. Drivers of slow vehicles start to rely on other drivers tooting them if they want to pass. They politely ask people to toot them by painting "Blow horn" signs on the backs and sides of their trucks. Artistic individuals spot an opportunity and, for a small fee, offer to paint ever more elaborate "Horn please" signs. Before you know it Volkswagen pre-fits cars it sells in India with slightly louder electromechanical horns. Now some truck drivers don't move over unless they're tooted and you have to toot if you want to pass. Viola. A co-evolving, intertwingled, history. Things are the way they are because they've got that way.

Large potholes in the road are common. Roads in India don't really have left lanes and right lanes so much as worse lanes and better lanes. I certainly don't recall seeing any white-line lane-dividers. What looks like total lane switching "indiscipline" is again simply sensible adaptive driving.

If traffic moved very fast the frequent lane switching would be downright dangerous. But traffic doesn't move fast. One reason is simply that lots of the traffic is old. Driving a new car in a sea of old cars could be quite dangerous (because of the brakes). Perhaps that's partly why the roads are regularly punctuated with pretty severe speed-bumps (actual ones as well as the pot holes). The speed-bumps keep your speed low even if you have a new car. So why buy a more expensive new car? Things are the way they are because they've got that way.

The traffic is also very varied. There are trucks, buses, masses of 3 wheeler took-tooks, huge numbers of motorbikes, push-bikes, push-trikes, pedestrians, carts, cows, you name it. As the traffic constantly switches lanes spaces of varying sizes constantly appear. No matter what the size of the space, there is always some form of road user just the right size to fill it. The variety encourages lane switching and the lane switching encourages variety. It gets that way.

Another reason traffic crawls is sheer numbers. More than a billion people Iive in India. There's a lot of traffic because there's a lot of people. And a lot of those people are young people. According to Wikipedia more than 50% of the Indian population is below the age of 25! The average middle-class home in a city such as Chennai is about 20 times the average middle class salary. Combine that with 10%+ interest rates and it's easy to see that a lot of people cannot afford to live in the city where they work. With so many young people, a hot climate, and a urban army of forced commuters it's no wonder there are so many motorbikes and buses, and increasingly, small cars. Things are the way they are because they got that way.

And a system that has got a certain way will, all things being equal, want to stay that way. A system will resist change. That's virtually a definition of a system. Only by resisting does it sit still long enough to be recognisable as something at all!

agile development in the large

is an excellent book by Jutta Eckstein (isbn 978-0932633576). As usual I'm going to quote from a few pages:

Quick feedback should be the first thing you introduce.

It is important that instead of the process being adopted it is adapted.

Starting with really short cycles seems to help implement the change to an agile process. If the cycles are short it is very difficult for the whole team to fall back into its old habits.

Learning and change processes are part of each other. Change is a learning process and learning is a change process.

Every agile process contains the following subtle steps
(1) reflection (awareness)
(2) learning
(3) change.

A plan is nothing; planning is everything. [Eisenhower]

If a project is on time and in budget it doesn't mean it was a successful project, but a successful estimate.

Methodologies do not produce skilled developers.

Stability is more negative than it is thought to be. [To stabilize something is to kill it]

A book is always a prevented dialogue.

viking laws

Several years ago I bought this postcard from Olso airport.

be brave and aggressive

• be direct
• grab all opportunities
• use varying methods of attack
• be versatile and agile
• attack one target at a time
• don't plan everything in detail
• use top quality weapons

be prepared

• keep weapons in good shape
• keep in shape
• find good battle comrades
• agree on important points
• choose one chief

be a good merchant

• find out what the market needs
• do not promise what you can't deliver
• do not demand overpayment
• arrange things so you can return

keep the camp in order

• keep things tidy and organized
• arrange enjoyable activities which strengthen the group
• make sure everyone does useful work
• consult all members of the group for advice

dig the trenches before the bombs start falling

If I write code without tests I will end up with low quality code. Worse - I'll discover that having written code without tests I've naturally ended up with a codebase that resists being tested. When this happens the codebase is not being 'malicious'. That's just that way it is. That's exactly the way I grew it. Testability isn't something that appears by magic. If I want a codebase to be testable I have to write tests for it as I go along. So that I find out just how testable it actually is and steer accordingly.

Sun Tzu put it very well in The Art of War when he wrote:

Plan for what is difficult while it is easy, do what is great while it is small.

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.

Being wrong

is an excellent book by Kathryn Schulz (isbn 978-0-06-117604-3). As usual I'm going to quote from a few pages:

One extremely good way to become wedded to a theory you just idly expressed is to have it contradicted... from noncommittal to evangelical in a matter of milliseconds.

We take our own certainty as an indicator of accuracy.

The instant an implicit assumption is violated, it turns into an explicit one.

When we ask people to look for something specific they develop a startling inability to see things in general.

The genius of statistics was that it did not ignore errors, it quantified them. [Laplace]

In ancient Indo-European, the ancestral language of nearly half of today's global population, the word 'er' meant "to move", "to set in motion", or simply "to go."

It is all too common for caterpillars to become butterflies and then maintain that in their youth they had been little butterflies.

the stakes of our mistakes.

Realizing that we are wrong about a belief almost always involves acquiring a replacement belief at the same time.

"fallor ergo sum" (I err, therefore I am) [St Augustine]

When other people reject our beliefs, we think they lack good information. When we reject their beliefs, we think we possess good judgement.

As with so many systems, the strengths of inductive reasoning are also its weaknesses. For every way that induction serves us admirably, it also creates a series of predictable biases in the way we think...
When a framework serves us well... we call it brilliant, and call it inductive reasoning. When it serves us poorly, we call it idiotic, and call it confirmation bias.

Being wrong can be funny; other people being wrong can be very very funny.

Without some kind of belief system in place, we wouldn't even know what kinds of questions to ask, let alone how to make sense of the answers.

Adapt - why success always starts with failure

is an excellent book by Tim Harford (isbn 978-0-349-12151-2). As usual I'm going to quote from a few pages:

Cross the river by feeling for stones [Deng Xiaoping]

Accepting trial and error means accepting error.

Darwin, a meticulous observer...

The art of success is to fail productively.

Complexity is a problem only in tightly coupled systems.

Make sure you know when you've failed, or you will never learn.

What Palchinsky realised was that most real-world problems are more complex than we think. They have a human dimension, a local dimension, and are likely to change as circumstances change. His method for dealing with this could be summarised as three 'Palchinsky principles'

• seek out new ideas and try new things
• when trying something new, do it on a scale where failure is survivable
• seek out feedback and learn from your mistakes as you go along

If we are to take the 'variation' part of 'variation and selection' seriously, uniformly high standards are not only impossible but undesirable.

When John Nagl served in Baghdad in 2003, he found that while his young inexperienced soldiers had the authority to kill, he - a major with a doctorate and a decade of experience - didn't have the authority to print his own propaganda pamphlets to counteract the clever PR campaign that the local insurgents were running.

Speciation - the divergence of one species into two separate populations - rarely happens without some form of physical separation.

Tight coupling means the unintended consequences proliferate so quickly that it is impossible to adapt to the failure or to try something different.

The first thing Timpson does when it buys another business is to rip out the electronic point-of-sale machines (there are always EPOS machines) and replace them with old fashioned cash registers. 'EPOS lets people at head office run the business', explains John Timpson. 'I don't want them to run the business.'

John Timpson describes one instance where he couldn't buy half-price happy hour drinks at a hotel bar, because midway through giving his order, the hour ended and the bar's computerised sales system refused to allow the half-price offer to be applied.

Timpson's company training manual describes the twenty easiest ways to defraud the company, making it clear that the company understands the risks it is running and trusts its employees anyway - and many people respond to being trusted by becoming more trustworthy.

A central point of the corporation, as a legal structure, is that it is supposed to be a safe space in which to fail. Limited liability companies were developed to encourage people to experiment, to innovate, to adapt - safe in the knowledge that if their venture collapsed, it would merely be the abstract legal entity that was ruined, not them personally.

Fail better. [Samuel Beckett]

sprints, time-boxing, and capacity

A team is doing Scrum with 3 week sprints. Suppose at the end of a sprint they've got nothing to done. What should they do? There's a strong temptation to ask for more time. To make this sprint a 4 week sprint. Most of the work in progress is 90% done, they say. Another week and things will have got to done, they say. It seems reasonable.

Trying to run systems beyond their capacity is not a good idea. In this situation Scrum's fixed-duration time-box constraint has served it's purpose admirably. The problem is not the choice of 3 weeks. Changing 3 weeks into 4 weeks is not addressing the problem. The problem is the team planned to pull in an amount of work and get it to done in 3 weeks. But they're not yet in control of their process - they don't know what their capacity is. They pulled in more than 3 weeks worth of work. Probably a lot more. But we just don't know!

In The Toyota Way, Jeffrey Liker writes:

Taiichi Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes.

Advice from a genius with a lifetime's experience. Toyota manufactures cars. It makes cars. Its production line is an actual line. If manufacturers are prone to overproduction imagine how much more prone software developers are! The things we make are not even physical things. In software, things are mostly invisible. It's difficult to manage what you can't see. In Quality Software Management volume 2, First-Order Measurement, Jerry Weinberg writes:

Without visibility, control is not possible.
If you can't see, you can't steer.

Rather than asking for another week, the team should really be thinking about addressing their real problem. Their real problem is that they're pulling in too much work. They have to somehow learn to pull in less work. So they can start to be in control of their process rather than their process being in control of them.

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 Toyota Way

is an excellent book by Jeffrey Liker (isbn 978-0-07-139231-0). As usual I'm going to quote from a few pages:

One day a Ford Taurus mysteriously disappeared. It had been in the factory so they could try fitting it with some prototype mirrors. When it vanished, they even filed a police report. Then it turned up months later. Guess where it was. In the back of the plant, surrounded by inventory.

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

…was that data was one step removed from the process, merely "indicators" of what was going on.

Building a culture takes years of applying a consistent approach with consistent principles.

It seems the typical U.S. company regularly alternates between the extremes of stunningly successful and borderline bankrupt.

Flow where you can, pull where you must.

When I interviewed [Fujio] Cho for this book, I asked him about differences in cultures between what he experienced starting up the Georgetown, Kentucky plant and managing Toyota plants in Japan. He did not hesitate to note that his number-one problem was getting group leaders and team members to stop the assembly line.

Every repair situation is unique.

The more inventory a company has,… the less likely they will have what they need [Taiichi Ohno]

I posit here that Toyota has evolved the most effective form of industrial organisation ever devised. At the heart of that organisation is a focus on its own survival. [John Shook]

You cannot measure an engineer's value-added productivity by looking at what he or she is doing. You have to follow the progress of an actual product the engineer is working on as it is being transformed into a final product (or service).

Everyone should tackle some great project at least once in their life. [Sakichi Toyoda]

Sense and respond

is an excellent book by Susan Barlow, Stephen Parry, and Mike Faulkner (isbn 1-4039-4573-X). As usual I'm going to quote from a few pages:

Continuous improvement… is not enough… what is needed also is continuous value creation.

…they continue to create products 'just in case' rather than 'just in time'.

The intelligent business therefore embraces voluntary evolution, designing its own fitness to survive and thrive.

...measure the value creation to value restoration ratio.

Most fast-food burger chains follow, to a large extent, the batch-and-queue principle… Contrast this kind of flow with the one-piece flow achieved by another fast-food company that makes sandwiches and 'subs'… What has been standardised therefore, is not the product but the production method...

Very often the traditional organisation passes work from one department to another in a batch-and-queue system, and with this approach it is not atypical to discover that a task that could be done in ten minutes may actually take ten days to complete. The reason for this is simple: the process is designed that way.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain.

Two options exist for businesses: to make offers to customers or to respond to customers' needs.

Is the customer purchasing an electric drill or holes in the wall?

Adaptiveness… cannot just be added on to an organisation's existing capabilities: the organisation itself must become adaptive.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain. The result is a critical mass of value creation around flow instead of around functions.

Responsibility

I had the pleasure of attending the Agilis conference in Iceland recently.

Christopher Avery gave an excellent keynote and spoke about the difference between accountability and responsibility; you are accountable to someone else but responsibility is personal.

He presented his six step ladder of responsibility:

• Responsibility
• Obligation
• Shame
• Justify
• Lay Blame
• Denial

For example, I'm typing this in TextEdit on my Macbook whilst on a train to XP Day. The font is small and my eyesight is fading. For a moment I struggled to discern the tif in the word Justify. I could almost hear a tiny voice inside my head starting to blame. But then I jumped to Responsibility because I realised the fault was not with TextEdit but with me. I simply enlarged the font size.

Christopher handed out a sheet expanding a little on the six step ladder above.

• Responsibility is owning your ability and power to create, choose, and attract. It's about your ability to make a response - to respond.
• Obligation is doing what you have to do instead of what you want to. As always, if you listen carefully, you can hear this distinction in patterns of speech "… but I have to …".
• Justify where we attempt to rationalise the blame, to use excuses for things being the way they are; we make things just in our mind.
• Shame is laying blame on oneself (often felt as guilt).
• Lay Blame (which is not a French verb ;-) is holding others at fault for causing something.

My son Patrick has Asperger's Syndrome and he has a strong tendency to blame. For example, if he bumps his elbow on the door he gets angry and blames the door. He finds it very difficult to move past this blame, to get inside a positive feedback loop which helps him become less clumsy. So I think laying blame is more than holding other people at fault, it can take the form of blaming anything - anything except oneself.

There is no best practice

I had the pleasure of speaking at the Agilis conference in Iceland recently. While preparing my slides on Deliberate Practice I was naturally thinking about the word practice. As far as I can tell, "Best practice" is the most common phrase with the word practice in it. I searched for "Best practice" on goggle and got over 270 million hits. I searched for "Better practices" on google and got a paltry 20 million hits.

Best practice…

• focuses on achieving someone else's perfect future state
• assumes there is only one best practice
• implies improvement beyond the best practice is impossible
• emphasises the noun practice
• fits with the waterfall-defined-fixed mindset
• doesn't start from where you are now

Better practises…

• focuses on improving your own imperfect present state
• assumes there are many possible better practices
• implies improvement beyond the best practice is always possible
• emphasises the verb - to practice
• fits with the agile-empirical-growth mindset
• starts from where you are now

Agile A-Z Keynote

I attended the excellent Agile .NET 2011 conference in Ghent, Belgium this week. Jason Gorman pulled out at the last minute and Erik asked me if I'd step in and do the keynote. I said yes of course and prepared this on the train+plane there.

An Agile A to Z

View more presentations from JonJagger.

Waiting work wall

One of the things I do a lot when visiting software groups is simply sit with individuals as they work. Sometimes the person I'm sitting next to is a really superb developer. They finish their work fast and to a high standard and hand the work on to the next person downstream. This next person may also be really skilled but their work might just inherently take longer. If the amount of work passed on exceeds the capacity of the next person then a growing batch of work-waiting-to-be-started-by-the-next-person will naturally form and grow.

This batch of work-waiting-to-be-started-by-the-next-person is waste. That's well known and well written about. What's not so obvious and not so well written about is how it encourages silos to form. It literally forms a barrier between the increasingly separated silos that form on either side of it.

Think of each waiting-work-item as a brick in a wall. But not a long, low, queue-shaped wall that's easy to see over. Rather, a short, high wall. One that you can't see over. One that hinders communication.

The amount of waiting-work between two silos is inversely proportional to the lack of communication between the two silos. The more waiting-work, the less the communication. The less communication the more waiting-work. Round and round it goes.

So, if you have some really superb developers then beware. They might be creating a downstream wall of waiting-work around which silos are forming.

ALE CyberDojo Ice Breaker

I ran a mass-participation CyberDojo "keynote" at the excellent ALE conference in Berlin recently. 10 laptops were setup with a Yahtzee refactoring exercise in Java. Over 200 people participated. The aim was not to write code - it was to mix people up and get lots of energy into the conference right at the start. I think it worked very well.

flow = speed x density

I attended the ALE conference in Berlin last week. It was excellent in many many ways. Lots of participants have written blog entries and I thought I would write a short one about just one of the many things I thought was really great. It was the above graph which Karl Scotland drew in his talk, The Science of Kanban.

Karl used this graph in the context of traffic.

• The green line is traffic Speed and it rises (to the right) from zero at the bottom left.
• The red line is traffic Density and it rises (to the left) from zero at the bottom right.
• The black line is traffic Flow and equals Speed x Density.

Speaking to Karl afterwards we discussed the analogy:

• Speed = cycle time. The time it takes from the moment a piece of work enters the system to the time it gets to Done.
• Density = work in progress. The amount of work that has entered the system but hasn't yet got to Done.

Karl also pointed out two feedback loops.

• Start on the density line (red) at zero (bottom right) and increase the density (move up and to the left). For a while increasing the density increases the flow. Increasing the flow causes the density to reduce. Thus you have a stabilizing feedback loop helping to increase the flow.
• As you continue to increase the density you drop over the top of the flow-curve.
• Now as the density increases the flow decreases. And decreasing the flow causes the density to further increase. Thus you have a different destabilizing feedback loop helping to decrease the flow.

Simple and effective. Thank you Karl.

QCon Deliberate Practice video

Videos are like buses. None for ages then two come along at once. I did this talk, on Deliberate Practice at the QCon conference in London earlier in the year (it's only just been put online). It's an extension of my 97 Things Every Programmer Should Know entry.

Six memos for the next millenium

is an excellent book by Italo Calvino (isbn 0-099-73051-0). As usual I'm going to quote from a few pages:

Lightness for me goes with precision and determination, not with vagueness and the haphazard... (One should be light like a bird and not like a feather)...

... even correctness of style is a question of quick adjustment, of agility of both thought and expression.

... each value or virtue I chose as the subject for my lecture does not exclude its opposite.

Poetry is the great enemy of chance, in spite of also being a daughter of chance.

On folio 265 of the Codex Atlanticus, Leonardo begins to jot down evidence to prove a theory of the growth of the earth. After giving examples of buried cities swallowed up by the soil, he goes on to the marine fossils found in the mountains and in particular to certain bones that he supposes must have belonged to an antediluvian sea monster. At this moment his imagination must have been caught by a vision of the immense animal as it was swimming among the waves. At any rate, he turns the page upside down and tries to capture the image of the animal, three times attempting a sentence that will convey all the wonder of that evocation.

It is useless at every circle to invent a new form of metarepresentation.

What tends to emerge from the great novels of the twentieth century is the idea of an open encyclopedia, an adjective that certainly contradicts the noun encyclopedia, which etymologically implies an attempt to exhaust knowledge of the world by enclosing it in a circle.

There is a type of work that, in the attempt to contain everything possible, does not manage to take on a form, to create outlines for itself, and so remains incomplete by its very nature.

... the collection of objects of which only one specimen exists.

The classical author who wrote his tragedy observing a certain number of known rules is freer that the poet who writes down whatever comes into his head and is slave to other rules of which he knows nothing.