How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
Preservation has become the best carrier of that moral force architecture needs if it is to have value beyond shelter.
Why are old buildings more freeing? They free you by constraining you.
It is much easier to continue than to begin. Less money is needed, as well as less time, and fewer people are involved, so fewer compromises are necessary.
How Buildings Learn: Chapter 6 - Unreal Estate
How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
Rushing is at the root of all lack of quality.
Form follows failure.
City lots...(as in parking lots). Their size is enormously influential. Small lots make for constant fine-grain adaptation instead of the sudden devastating changes that can come with large parcels. Everything depends on the pattern of ownership of the land.
American planners always take their inspiration from Europe's great cities and such urban wonders as the Piazza San Marco in Venice, but they study the look, never the process. .... Venice is a monument to a dynamic process. Not to great urban planning.
As usual, the rate of change is everything.
Chris Alexander agrees: The money is all wrong in most buildings, and it's crucial. There should be more in basic structure, less in finish, more in maintenance and adaptation.
Work done in haste is necessarily shoddy, a house of cards. On a go-fast schedule there is no margin for a single error, and error is inevitable. High risk, high loss. The opposite strategy is much surer, because the errors are piecemeal and correctable. When you proceed deliberately mistakes don't cascade, they instruct. Low risk plus time equals high gain.
Rushing is at the root of all lack of quality.
Form follows failure.
City lots...(as in parking lots). Their size is enormously influential. Small lots make for constant fine-grain adaptation instead of the sudden devastating changes that can come with large parcels. Everything depends on the pattern of ownership of the land.
American planners always take their inspiration from Europe's great cities and such urban wonders as the Piazza San Marco in Venice, but they study the look, never the process. .... Venice is a monument to a dynamic process. Not to great urban planning.
As usual, the rate of change is everything.
Chris Alexander agrees: The money is all wrong in most buildings, and it's crucial. There should be more in basic structure, less in finish, more in maintenance and adaptation.
Work done in haste is necessarily shoddy, a house of cards. On a go-fast schedule there is no margin for a single error, and error is inevitable. High risk, high loss. The opposite strategy is much surer, because the errors are piecemeal and correctable. When you proceed deliberately mistakes don't cascade, they instruct. Low risk plus time equals high gain.
How Buildings Learn: Chapter 5 - Magazine Architecture: No Road
How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
Architects offered themselves as providers of instant solutions, and only the look of a building gives instant gratification.
In the 1980's, 80 percent of the ever-growing post-construction claims against architects were for leaks. Domes leaked, always. Worst of all, domes couldn't grow or adapt. What's good about 90-degree walls: they don't catch dust, rain doesn't sit on them, easy to add to; gravity, not tension holds them in place. We are 90 degrees to the earth.
The specious old-box is old because it is profoundly adaptive.
Instead of steady accumulation, the business of contemporary architecture is dominated by two instants in time. One is the moment of go-ahead...The other is the moment of hand-over.
All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed. A lot of the time now you see buildings that look exactly like their models. That's when you know you're in trouble.
There is real misunderstanding about whether buildings are something dynamic or something static.
Architects think of a building as a complete thing, while builders think of it and know it as a sequence.
The race for finality undermines the whole process. In reality finishing is never finished.
Unchallenged practices persist for decades.
Admiration is from a distance and brief, while love is up close and cumulative.
The needed conversion is from architecture based on image to architecture based on process.
Architects offered themselves as providers of instant solutions, and only the look of a building gives instant gratification.
In the 1980's, 80 percent of the ever-growing post-construction claims against architects were for leaks. Domes leaked, always. Worst of all, domes couldn't grow or adapt. What's good about 90-degree walls: they don't catch dust, rain doesn't sit on them, easy to add to; gravity, not tension holds them in place. We are 90 degrees to the earth.
The specious old-box is old because it is profoundly adaptive.
Instead of steady accumulation, the business of contemporary architecture is dominated by two instants in time. One is the moment of go-ahead...The other is the moment of hand-over.
All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed. A lot of the time now you see buildings that look exactly like their models. That's when you know you're in trouble.
There is real misunderstanding about whether buildings are something dynamic or something static.
Architects think of a building as a complete thing, while builders think of it and know it as a sequence.
The race for finality undermines the whole process. In reality finishing is never finished.
Unchallenged practices persist for decades.
Admiration is from a distance and brief, while love is up close and cumulative.
The needed conversion is from architecture based on image to architecture based on process.
How Buildings Learn: Chapter 4 - Houseproud: The High Road
How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
The High Road is high-visibility, often high-style, nearly always high-cost. This is the way to grow a High Road building. Take it by stages with constant minute refinement. There's a huge time lag between when you need something and when you actually get it. Trust, intimacy, intense use, and time are what made these buildings work so well.
The High Road is high-visibility, often high-style, nearly always high-cost. This is the way to grow a High Road building. Take it by stages with constant minute refinement. There's a huge time lag between when you need something and when you actually get it. Trust, intimacy, intense use, and time are what made these buildings work so well.
How Buildings Learn: Chapter 3 - Nobody Cares What You Do In There: The Low Road
How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
What do people do in buildings when they can do almost anything they want?
What do people do in buildings when they can do almost anything they want?
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".
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."
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."
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."
How Buildings Learn: Chapter 1 - Flow
How Buildings Learn by Stewart Brand is a really great read about the underlying processes that govern the evolution of buildings over time.
At the heart of this book is the idea of change - of time. That buildings change. That people change them. That the elements change them. This, fundamentally, is the reason the parallels with software leap off every page. Understanding and managing change is arguably the fundamental aspect of understanding and managing the process of developing software. Software isn't written perfectly in a sudden flash. It takes time. It takes lots of small changes.
The author writes "My approach is to examine buildings as a whole - not just whole in space, but whole in time". He laments the aphorism "Form ever follows function" written in 1896 by Louis Sullivan (A Chicago high-rise designer) because "it misled a century of architects into believing that they could really anticipate function". The idea is to aim for software that gets better over time. Or, more accurately, that is capable of getting better over time.
At the heart of this book is the idea of change - of time. That buildings change. That people change them. That the elements change them. This, fundamentally, is the reason the parallels with software leap off every page. Understanding and managing change is arguably the fundamental aspect of understanding and managing the process of developing software. Software isn't written perfectly in a sudden flash. It takes time. It takes lots of small changes.
The author writes "My approach is to examine buildings as a whole - not just whole in space, but whole in time". He laments the aphorism "Form ever follows function" written in 1896 by Louis Sullivan (A Chicago high-rise designer) because "it misled a century of architects into believing that they could really anticipate function". The idea is to aim for software that gets better over time. Or, more accurately, that is capable of getting better over time.
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:
Size matters too. Even the smallest mistake can kill an animal/program. In [2] Richard Gabriel writes:
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:
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
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
Benjamin Franklin's Prose Practice
I've finished reading Benjamin Franklin's Autobiography. The thoroughness of his deliberate prose practice is impressive:
About this time I met with an odd volume of the Spectator. It was the third. I had never before seen any of them. I bought it, read it over and over, and was much delighted with it. I thought the writing excellent, and wished, if possible, to imitate it. With this view I took some of the papers, and, making short hints of the sentiment in each sentence, laid them by for a few days, and then, without looking at the book, tried to complete the papers again, by expressing each hinted sentiment at length, and as fully as it had been expressed before, in any suitable words that should come to hand. Then I compared my Spectator with the original, discovered some of my faults, and corrected them. But I found I wanted a stock of words, or a readiness in recollecting and using them, which I thought I should have acquired before that time if I had gome on making verses; since the continual occasion for words of the same import, but of different length, to suit the measure, or of different sound for the rhyme, would have laid me under a constant necessity of searching for variety, and also have tended to fix that variety in my mind and make me master of it. Therefore I took some of the tales and turned them into verse; and, after a time, when I had pretty well forgotten the prose, turned them back again. I also sometimes jumbled my collection of hints into confusion, and after some weeks endeavored to reduce them into the best order, before I began to form the full sentences and complete the paper. This was to teach me method in the arrangement of my thoughts. By comparing my work afterwards with the original, I discovered many faults and amended them;
The Secrets of Consulting
is the title of an excellent book by Jerry Weinberg.
As usual I'm going to quote from a few pages:
There's always a problem. It's always a people problem.
People want training that makes them better adapted to their present task, rather than training that makes them more adaptable to future tasks.
Consulting is not a test for the consultant, it's a service to the client.
Things are the way they are because they got that way.
Study for understanding, not for criticism.
Don't be afraid to cultivate your unconscious.
Cucumbers get more pickled than brine gets cucumbered.
The trick to earning trust is to avoid all tricks.
Never promise anything. Always keep your promise.
When technology pisses me off (3)
This time it's a digital camera. Scroll through the photos on the camera and you can see them all. Connect to a Windows XP laptop and only some of them appear. If you're involved in making technology I plead with you to at least make it do the basics correctly. If it does the basics correctly I can forgive you when rarely used extra frills don't work. What's unforgivable is when the basics don't work.
Quite by chance, I see David Hansson of Ruby on Rails fame is twittering he's having numerous problems making calls from his iPhone. Same thing. RUBBISH.
Quite by chance, I see David Hansson of Ruby on Rails fame is twittering he's having numerous problems making calls from his iPhone. Same thing. RUBBISH.
C/C++ 2 phase unit-testing again
In my
previous blog entry on the 2-phase unit-testing idea the code sketch looked like this:
/* test.h */ #define TEST(name) if (run_phase(suite, name)) ...
/* wibble_tests.c */
#include "test.h"
#include "wibble.h"
...
static void wibble_tests(test_suite * suite)
{
...
TEST("fprintf failure inside wibble")
{
int expected = 42;
int actual = wibble(4, 2);
/* assert expected == actual */
}
...
}
A follow on idea from this to make the string literal test names globally available. Suppose the wibble function looks like this:
/* wibble.c */
#include "wibble.h"
#include <stdio.h>
int wibble(int lhs, int rhs)
{
...
ret = fprintf(stdout, "%d,%d", lhs, rhs);
if (ret < 0)
...
}
And you want to mock fprintf.
You can move the definition of wibble() into its own .func file like so:
/* wibble.c */ #include "wibble.h" #include <stdio.h> #include "wibble.func"
/* wibble.func */
int wibble(int lhs, int rhs)
{
...
ret = fprintf(stdout, "%d,%d", lhs, rhs);
if (ret < 0)
...
}
This allows you to isolate wibble() by #including the wibble.func file.
This is quite brutal but it shouldn't affect the behaviour and brutality can be appropriate when your trying to write characterisation tests because you don't have any tests yet.
The last step is to make run_phase() access the suite parameter itself (rather than being passed it) so the TEST macro can be used anywhere:
/* test.h */ #define TEST(name) if (run_phase(name)) ...
/* wibble_tests.c */
#include "test.h"
typedef int mock_file;
static mock_file * stdout = 0;
static int fprintf(mock_file * mf, const char * format, ...)
{
TEST("fprintf failure inside wibble")
{
return -2;
}
...
}
#include "wibble.func"
static void wibble_tests(void)
{
...
TEST("fprintf failure inside wibble")
{
int expected = 42;
int actual = wibble(4, 2);
/* assert expected == actual */
}
...
}
The Machine That Changed The World
...is the title of a book by James Womack, Daniel Jones, and Daniel Roos. It's subtitled How Lean Production Revolutionized the Global Car Wars. As usual I'm going to quote from a few pages:
In striking contrast to the mass-production plant, where stopping the line was the responsibility of the senior line manager, Ohno placed a cord above every work station and instructed workers to stop the whole assembly line immediately if a problem emerged that they couldn't fix. Then the whole team would come over to work on the problem.
Lean distribution will form the front end of a system that is driven by the needs of the customer, not by the needs of the factory.
The ultimate cause is almost always an organizational problem.
Workers at mass-production plants learn no skills.
Japanese companies do not believe they can turn around existing mass-production facilities.
In Japan...practically all hiring in companies is from the bottom only.
Anything that is new is likely to be misunderstood, typically by attempts to explain the new phenomenon in terms of traditional categories and causes.
The central problem is people - how to reward and motivate thousands of individuals from many countries and cultures so that they work in harmony.
When technology pisses me off (2)
A Buzz Lightyear DVD this time. My son Patrick has Asperger's Syndrome. He likes to watch the same film over and over again. He likes to watch the film over and over again. Not the adverts. Going to the cinema is not like watching a DVD at home. DVD's that won't let you skip the adverts when you're watching the DVD for the umpteenth time are RUBBISH
When technology pisses me off (1)
I've just come back from a great days fishing on the river Wye with my mate Brian. To get to the spot we tried to use a sat-nav. A Garmin something or other. It was Brian's. I don't have a sat-nav because on the few occasions I've used one in the past they have been universally rubbish. I'm sure when the work they're great - it's just that they've failed to work for me with sufficient regularity that they no longer get a chance. And this time it was more of the same. Brian spent about 20 minutes trying to enter GL17 9NU, the post-code of our destination. It refused to let him enter the post-code. He typed in GL1 (on a keyboard display that was not qwerty and consequently slowed you down, why?) and it jumped to a screen showing GL16 something or other. Various other options were tried. Nope. It flatly refused to play ball. I've learned that if something's not working there's no point carrying on trying to force it to work. That very rarely works. So we abandoned it and headed off in the general direction relying on good old paper map technology. Much later, quite by chance, we discovered what was going on. The previous sat-nav trip was for our first days fishing in Builth Wells, which is in Wales. Because of this it seemed to have got stuck in Wales. It was only accepting post-codes in Wales. Why doesn't it just let you enter the post-code you want to enter and then see if that post-code is in Wales or England? RUBBISH.
The fifth discipline
...is an excellent book by Peter Senge. It's subtitled The Art and Practice of the Learning Organisation.
As usual I'm going to quote from a few pages:
Surprisingly few adults work to rigorously develop their own personal mastery.
More often than we realize systems cause their own crises, not external forces or individuals' mistakes.
Living systems have integrity. Their character depends on the whole.
In systems thinking it is an axiom that every influence is both a cause and an effect. Nothing is ever influenced in just one direction.
One of the highest leverage points for improving system performance, is the minimization of system delays.
Learning is eventually always about action.
The total absence of meaningful practice or rehearsal is probably the predominant factor that keeps most management teams from being effective learning units.
No practice, no learning.
Don't push growth; remove the factors limiting growth.
Most organizations are dominated by linear thinking, not systems thinking. The dominance of the event mentality tells people that the name of the game is reacting to change, not generating change.
It cannot be stressed too much that team learning is a team skill.
You cannot change how someone thinks, but you can give them a tool the use of which leads them to think differently [Buckminster Fuller].
Sensing and acting locally is exactly how complex living systems work.
Hierarchy is antithetical to dialogue, and it is difficult to escape hierarchy in organisations.
Systems Thinking in the Public Sector
...is the title of a book by John Seddon. As usual I'm simply going to quote from a few pages:
Standardization constrains a system's ability to absorb variety.
...the test of a good measure: does it help us understand and improve performance.
focus on costs and costs will rise, focus on flow and costs will fall.
There are two kinds of customer demand: value demand and failure demand.
Waste is man made.
People's behaviour is a product of their system.
Systems Thinking
Human beings have evolved a very strong association that cause and effect are simple and linear; that cause and effect are local in space and local in time. We are not good at seeing the non-linear effects of our actions; the effects over distance and especially over time. Here's something a friend emailed me:
Last week I found that the guys had not checked in a big chunk of library code. It was in the place where common tool-chains were getting invoked, so no one noticed. They changed something and I was seeing sudden breakages even with older versions of the code which was working. They didn't even bother to put it into the version control. I just couldn't believe, people can work this way. I immediately put it into the svn.
Here's what I replied...
Why do you think they hadn't put it in svn? Because at some level they associate the pain of putting it into svn as being greater than the pain of not putting it into svn plus living in a messy kitchen! And who can blame them when helpful people like yourself come along and clean up their mess! They are probably hardly even consciously aware that have the option of putting it into svn themselves. If they haven't put it into svn for N weeks then that is the behaviour that has become their norm. And things that don't change are not seen or thought about. That's abstraction! You are part of the vicious cycle! You are helping to perpetuate their behaviour. You are part of the system!
A more congruent approach would have been to sit next to them and talk them through what they needed to do to tidy up the mess. You absolutely mustn't do any part of it for them. Only if they actually do it themselves will they have a chance of not repeating the situation. They have to type the keystrokes at the keyboard. Remember, it is trivial for you to do it, but for them it will mean working through some level of associated pain. That is not their "fault". They are simply, in this case, less experienced than you. You simply sit next to them and calmly, patiently, ever so patiently, talk them through it in a non threatening, non blaming way.
Generativity
Generativity is a tricky thing. It's when you work to achieve a desired outcome indirectly. The indirection helps to hide the desired outcome from your conscious mind. This can be important, because your mind has a tendency to interfere with the desired outcome. It's an example of Le Chatelier's Principle - Systems tend to oppose their own function.
Timothy Gallwey, a tennis coach, tells of a great example of generativity. He observed that direct verbal instructions such as ‘Keep your eye on the ball’ are ineffective because players find it hard to keep the direct advice sharp in their minds and at the same time to follow the advice. Instead Gallwey told the player to say the word "bounce" when the ball bounced in front of them and then the word "hit" as they hit the ball. Players found this alternative advice much easier to retain while playing. And since you have to watch the ball carefully to know the exact moment when it bounces and when you hit it it has the side effect of helping you keep your eye on the ball!
Timothy Gallwey, a tennis coach, tells of a great example of generativity. He observed that direct verbal instructions such as ‘Keep your eye on the ball’ are ineffective because players find it hard to keep the direct advice sharp in their minds and at the same time to follow the advice. Instead Gallwey told the player to say the word "bounce" when the ball bounced in front of them and then the word "hit" as they hit the ball. Players found this alternative advice much easier to retain while playing. And since you have to watch the ball carefully to know the exact moment when it bounces and when you hit it it has the side effect of helping you keep your eye on the ball!
The Hawk and the Rabbit
When I'm consulting I sometimes ask a group what the word "agile" means to them. Their response invariably centers on the idea of speed. Agility is not primarily about speed...
A few years ago I was standing on the roof of my house (the loft was being converted - it's not something I normally do). I spotted a bird of prey (a hawk I think) circling overhead. Rabbits lived in the field opposite and I wondered if I the hawk would swoop on one - something I'd never seen before. And with that the hawk began to dive! It was clearly targeting a young rabbit sitting by the far hedge... The rabbit sensed the danger, stopped eating, and started running for its life... The hawk changed direction and kept after the speeding youngster... got very close... reached out with its talons... was about to make its kill.... And at that exact moment the rabbit changed direction. I don't mean it veered off slightly to the left or slightly to the right. I mean one moment it was running as fast as it could along the hedge and the next moment, with almost no discernible pause or reduction in speed, it was running in the opposite direction back to where it had came from. It was quite something. The rabbit was certainly fast but the hawk was faster. What saved the rabbit was its nimbleness. It's agility.
Agility isn't how fast you can keep going in the same direction; agility is how easily you can change direction.
Footnote
The hawk appeared to have all the advantages during the chase. For one it had gravity on its side, and for two it only had to overcome air-resistance. The rabbit was expending a lot more energy. But the increased friction with the ground helped the rabbit make a sudden change of direction.
Subscribe to:
Posts (Atom)