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.

More C macro magic - CASES

I was thinking about the PP_NARG macro this morning. It occurred to me that you could use it to create a macro for a range of case labels in a switch statement! Instead of writing this:

void eg(int n)
{
    switch(n)
    {
        case 1:
        case 2:
        case 3:
        case 4:
        case 5:
            printf("1..5\n"); 
            break;
    }
}

You could write this:

void eg(int n)
{
    switch(n)
    {
        CASES(1,2,3,4,5):
            printf("1..5\n"); 
            break;
    }
}

and the C99 magic macro is:

#define PP_NARG(...) \
    PP_NARG_(__VA_ARGS__, PP_RSEQ_N())

#define PP_NARG_(...) \
    PP_ARG_N(__VA_ARGS__)

#define PP_ARG_N(_1, _2, _3, _4, _5, _6, N, ...)   N

#define PP_RSEQ_N() \
    6,5,4,3,2,1,0

#define CASES(...) \
    CASES_(PP_NARG(__VA_ARGS__), __VA_ARGS__)

#define CASES_(N,...) \
    CASES_N(N,__VA_ARGS__)

#define CASES_N(N,...) \
    CASES_ ## N(__VA_ARGS__)

#define CASES_1(a)     case a
#define CASES_2(a,...) case a: CASES_1(__VA_ARGS__)
#define CASES_3(a,...) case a: CASES_2(__VA_ARGS__)
#define CASES_4(a,...) case a: CASES_3(__VA_ARGS__)
#define CASES_5(a,...) case a: CASES_4(__VA_ARGS__)

Weinberg on writing

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

Writer's block is not a disorder in you, the writer. It's a deficiency in your writing methods - the mythology you've swallowed about how works get written - what my friend and sometime coauthor Tom Gilb called your "mythology".

It's not the number of ideas that blocks you, it's your reaction to the number of ideas.

A trigger is a small amount of input energy that sets off a large amount of output energy.

"You know, there would be no problem raising kids if only you could throw away the first one."

The essence of the Fieldstone Method is to gather great quantities of words and then to discard a slightly less great quantity.

Learning, it seems, is a matter of repeated attempts, until one finds a teacher, a book, a film, an approach, a flash, or something that finally gets the point across.

About one third of the time, the problem turns out to be that the passage didn't mean anything, or meant several things at once.

Mozart used dice to produce ideas for musical themes, and even designed a dice game for composing new minuets.

Often, in the middle of a game, an idea will pop into my mind, and I will immediately pop it into the window I have open for the manuscript. Sometimes, I continue writing from that idea for hours. When I finish, I'm generally surprised to find a half-finished solitaire game in progress.

C macro magic - PP_NARG

I've just spent two days delivering my C Foundation course to the massively talented people at Cisco (nee Tandberg nee Codian) in Langley. One of the guys on the course called Alex showed me an amazing C99 macro that counts the number of parameters. The capacity of C to surprise me with something new never ceases to amaze. Here it is (cut down to handle just 6 parameters to save space):

#include <stdio.h>

#define PP_NARG(...) \
    PP_NARG_(__VA_ARGS__, PP_RSEQ_N())

#define PP_NARG_(...) \
    PP_ARG_N(__VA_ARGS__)

#define PP_ARG_N( \
    _1, _2, _3, _4, _5, _6, N, ...)   (N)

#define PP_RSEQ_N() \
    6,5,4,3,2,1,0

int main(void)
{
    printf("%d\n", PP_NARG(a,b+c+d)); // 2
    printf("%d\n", PP_NARG(a,b,c,d,e+f)); // 5
    return 0;
}

Alex mentioned it doesn't work for zero parameters - it incorrectly returns one. Of course I can't resist seeing if I can fix that. After playing around a bit I've come up with this which seems to work.

#define PP_NARG(...) \
    PP_NARG_(sizeof #__VA_ARGS__, __VA_ARGS__, PP_RSEQ_N())

#define PP_NARG_(delta, ...) \
    PP_ARG_N(delta, __VA_ARGS__)

#define PP_ARG_N( \
    delta, _1, _2, _3, _4, _5, _6, N, ...)   (N - ((delta)==1))

#define PP_RSEQ_N() \
    6,5,4,3,2,1,0

Alex joked that at parties he's tried to impress girls with this macro. Of course he increases the number of parameters to 128. Size matters after all. And naturally he boasts not only of the macro's size but also of it capacity for expansion!

Beating the system

is an excellent book edited by Russell Ackoff and Sheldon Rovin (isbn 1-57675-330-1). As usual I'm going to quote from a few pages:

Beating the system can be a serious and occasionally risky business; some courage is needed.

Bureaucrats are usually empowered to say no to even reasonable requests, but they cannot say yes to them. This requires passing requests to a higher authority. Saying no inflates bureaucrats' self-images.

Nothing beats knowing how the system you're trying to beat actually works because the chances are that no one else knows, with the possible exception of secretaries.

We do not try to cure headache by perfuming brain surgery. Rather, we put a pill in our stomach.

The usual way of doing things often gets in the way of doing things.

Time is our only absolutely nonrenewable and, thus, most highly valued resource. To place a low value on another's time is to show a lack of respect for that person.

Persistence is a fundamental attribute of a system beater.

In most workplaces explicit and implicit assumptions often constrain behaviour.

Implicit assumptions lead to behaviours that are carried out automatically, without thought, and these behaviours constitute an organisation's or a society's culture. Culture is what we do when we do not consciously decide what to do.

Most assumptions made in and about organisations usually go unquestioned, and their validity is taken to be self-evident, despite Ambrose Bierce's (1967,289) admonition that "self-evident" means evident to oneself and no one else. "Obvious" does not mean "requiring no proof" but "no proof is desired."

No particular virtue exists in doing things the way they've always been done and in thinking about things in the way they've always been thought about.

Undesirable customs persist because they are tolerated without thought.

Effective police officers think like criminals; effective criminals think like police officers.

The major obstructions between a person and what he or she wants is not "out there" but in the person's mind.

A problem tends to be placed into the discipline of the one who first identifies it.

Problems are not defined by disciplines, although disciplinarians think so.

Sclumberger Japan

I visited Japan for the first time recently. I taught an Object Oriented Analysis and Design course for Schlumberger at Machida. The software metier there is a lovely man called Shin'ichi Watanabe who made me feel very welcome. He took me to a proper Japanese restaurant (which seated at most about 8 people) where you had to take your shoes off. The food was delicious as was the saki.

Leverage points

Is an excellent online pdf by Donella Meadows. As usual here are some snippets that spoke to me:

Counterintuitive. That's Forrester's word to describe complex systems.

Parameters are the points of least leverage on my list of interventions.

That's the difference between a lake and a river. You hear about catastrophic river floods much more often than catastrophic lake floods, because stocks that are big, relative to their flows, are more stable than small ones.

Often you can stabilise a system by increasing the capacity of a buffer. But if a buffer is too big, the system becomes inflexible. It reacts too slowly.

If you're trying to adjust a system state to your goal, but you only received delayed information about what the system state is, you will overshoot and undershoot.

Even with immense effort at forecasting, almost every centralised electricity industry in the world experiences long oscillations between overcapacity and undercapacity. A system just can't respond to short-term changes when it has long-term delays.

Delays that are too short cause overreaction, "chasing your tail", oscillations amplified by the jumpiness of the response. Delays that are too long caused damped, sustained, or exploding oscillations, depending on how much too long. At the extreme they cause chaos. Overlong delays in a system with a threshold, a danger point, a range past which irreversible damage can occur, cause overshoot and collapse.

The great push to reduce information and money transfer delays in financial markets is just asking for wild gyrations.

They [feedback loops] may not be very visible. But their presence is critical to the long-term welfare of the system. One of the big mistakes we make is to strip away these "emergency" response mechanisms because they aren't used often and they appear to be costly.

Democracy worked better before the advent of the brainwashing power of centralised mass communications.

A global economy makes necessary a global government.

Reducing the gain around a positive loop - slowing the growth - is usually a more powerful leverage point in systems than strengthening negative loops.

Missing feedback is one of the most common causes of system malfunction.

As the fish get more scarce and hence more expensive, it becomes more profitable to go out and catch them. That's a perverse feedback, a positive loop that ends in collapse.

Power over the rules is real power.

The most stunning things living systems and social systems can do is to change themselves utterly by creating whole new structures and behaviours. In biological systems that power is called evolution. In human society it's called technical advance or social revolution. In systems lingo, it's called self-organization.

The ability to self-organize is the strongest form of system resilience. A system that can evolve can survive almost any change, by changing itself.

One aspect of almost every culture is the belief in the utter superiority of that culture.

Societies… resist challenges to their paradigm harder than they resist anything else.

The power to transcend paradigms… It is to let go into Not Knowing, into what Buddhists call enlightenment.

It is in this space of mastery over paradigms that people throw off addictions, live in constant joy, bring down empires, found religions, get locked up or "disappeared" or shot, and have impacts that last for millennia.

Are your lights on?

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

Having followed our natural problem-solving tendencies, we have rushed right into solutions. Perhaps it would be wiser to ask a few questions before stating answers.

A problem is a difference between things as desired and things as perceived.

Don't take their solution method for a problem definition.

Each solution is the source of the next problem.

Designers - special people whose job it is to solve problems, in advance, for other people.

Approaching public servants with courtesy and respect for their humanity and competence will, for the most part, evoke humanity and competence.

The source of the problem is most often within you.

The source of a problem often contains some key element in its resolution.

In spite of appearances, people seldom know what they want until you give what they ask for.

We never have enough time to do it right, but we always have enough time to do it over.

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.

Cognitive surplus

is an excellent book edited by Clay Shirky (isbn 978-1-846-14217-8). As usual I'm going to quote from a few pages:

The real gap is between doing nothing and doing something.

The easier it is for the average person to publish; the more average what gets published becomes.

Language lets us work at the right level of ambiguity.

When opportunity changes a lot, behaviour will as well.

A surprise is the feeling of an old belief breaking.

Many of our behaviours are held in place by inconvenience, and they're quick to disappear when the inconvenience does.

Knowledge is the most combinable thing we humans have.

Behaviour is motivation filtered through opportunity.

The behaviour you're seeing is the behaviour you've designed for.

In participatory systems, "average" is an almost useless concept.

The task isn't just to get something done; it's to create an environment in which people want to do it.

Air-luggage

I went to the excellent Agile Cambridge conference recently. At breakfast one morning I was chatting to Julian Fitzell and Jason Ayers and we got to discussing luggage when flying. I always take nothing but hand-luggage. However, it's true that checking luggage into the hold does have some advantages. I think you're viewed with increased suspicion if you fly long haul with only hand-luggage. That's certainly the impression I sometimes get when flying with just hand-luggage to Melbourne say. And for another the airline has a much greater incentive to ensure you make your flight if you've checked luggage into the hold. Otherwise they have to resort to a round of luggage-rummage to remove your bags.

We had a lot fun designing a potential solution. Simply check in an empty suitcase! But it would be very inconvenient carrying an empty suitcase just to check it in. So how about an inflatable suitcase! A self blow-up suitcase would be too inconvenient so it would have to contain a cartridge which you cracked open, mixing two chemicals and causing an expansion of gases. It could double as something to sit on too.

Airline companies have limits on the heaviness of luggage but we can't imagine they have limits on its lightness. But lightness could cause problems. We wouldn't want an unsuspecting luggage-handler falling over backwards trying to lift super-light air-luggage imagining it was normal heaviness. So we might have to put on stickers "Warning: Very Light". If the airlines introduced a minimum weight we might have to add weights pre-sealed inside the air-luggage. We could add words cast in metal to give the x-ray machine handlers something to read!

As well as a basic air-suitcase we can imagine some deluxe versions along with several spin off products. An executive version which, when inflated, includes a non-retractable carrying handle and non-wheeling wheels. And a selection of self-attach stickers naming various exotic foreign destinations such as Hawaii, Alaska, and Antarctica. And of course, there is huge potential for air luggage in shapes other than plain suitcases. A guitar for example. A true air-guitar.

Naturally the air-luggage would come pre-manufactured with a fake luggage tag. The address on all the tags would be the same - the factory where the air-luggage was made. That way we could reuse and recycle, reducing our costs and increasing our profits.

As a bonus we would actively look into ways of increasing the chance the airline lost your air-luggage. Each piece of air-luggage would come with lost-luggage claims-forms for all major airlines. These would be pre-filled-in by a sophisticated computer program enabling you to make a claim for all the lost air-items your air-luggage contained.