In a hotel in Beijing. I wonder what the words say? "Please press the buttons gently" perhaps?
I hope you don't want floor 7
In a hotel in Beijing. I wonder what the words say? "Please press the buttons gently" perhaps?
Use-Case cartoon speech bubbles
UML Use Case/Scenario ellipses look quite similar to cartoon speech bubbles. And each ellipse is of course supposed to be "spoken" by an actor. So sometimes when I'm coaching/training/etc I cut out ellipse shaped pieces of card and do some role playing.
You can have fun too. For example, developers often phrase their use-cases from the implementation perspective rather than from the actor's perspective. So when they write "Lend a Book" as the name of their Use Case, you can get them to actually try it. Pretend your inside a library, give them a book, and ask them to role play their use case. Like this... (the headband stops their arms from aching)
At which point someone role playing a Librarian can react like this...
...which makes everyone realize they should really have written this:
You can have fun too. For example, developers often phrase their use-cases from the implementation perspective rather than from the actor's perspective. So when they write "Lend a Book" as the name of their Use Case, you can get them to actually try it. Pretend your inside a library, give them a book, and ask them to role play their use case. Like this... (the headband stops their arms from aching)
At which point someone role playing a Librarian can react like this...
...which makes everyone realize they should really have written this:
Talent is Overrated
is the title of another excellent book (isbn 1857885198) by Geoff Colvin. As usual I'm going to quote from a few pages:
Deliberate practice is not what most of us do when we think we're practising.
Most organizations are terrible at applying the principles of great performance. Many companies seem arranged almost perfectly to prevent people from taking advantage of these principles for themselves.
nothing, it turned out, enabled any group to reach any given grade without putting in those hours. ... There is absolutely no evidence of a 'fast track' for high achievers.
memory ability is very clearly created rather than innate.
General Electric CEO Jeff Immelt has been clear about what the company is looking for: someone who is externally focused, is a clear thinker, has imagination, is an inclusive leader, and is a confident expert.
The roadblocks we face seem to be mostly imaginary.
Jerry Rice was the greatest because he worked harder in practice and in the off-season that anyone else; he spent very little time playing football; he designed his practice to work on his specific needs; he did much of the work on his own; it wasn't fun; he defied the conventional limits of age.
Practice is so hard that doing a lot of it requires people to arrange their lives in particular ways.
The advantage of practice was cumulative.
Deliberate practice requires that one identify certain sharply defined elements of performance that need to be improved, and then work intently on them.
Practicing without feedback is like bowling through a curtain that hangs down to knee level. You can work on technique all you like, but if you can't see the effects, two things will happen: You won't get any better, and you'll stop caring.
Feedback? At most companies this is a travesty, consisting of an annual performance review dreaded by the person delivering it and the one receiving it. Even if it's well done, it cannot be effective. Telling someone what he did well or poorly on a task he completed eleven months ago is just not helpful.
Practice is designed, so it can be designed well or badly.
Great performers never allows themselves to reach the automatic, arrested-development stage in their chosen fields. The essence of practice, which is constantly trying to do the things one cannot do comfortably, makes automatic behavior impossible.
In fact what they [great performers] have achieved is the ability to avoid doing it automatically.
It's Your Ship
is the title of an excellent book by Michael Abrashoff (isbn 0446529117).
As usual I'm going to quote from a few pages:
A recent Gallup study found that when people leave their companies, 65 percent of them are actually leaving their managers.
What I suddenly realized was that I had the power to do this all along. I just never had the self-confidence.
Something happened as a result of those interviews. I came to respect my crew enormously.
Secrecy spawns isolation, not success.
No matter how fantastic your message is, if no one is receiving it, you aren't communicating.
You earn trust only by giving it.
More often than not, bureaucracies create rules and then forget why they were needed in the first place, or fail to see that the reasons for them no longer exist.
Once leadership opportunities are squandered, you can never get them back.
If a rule doesn't make sense, break it.
If a rule does make sense, break it carefully.
I felt as small as a man could. I had just had my core values calibrated by someone half my age.
One-size-fits-all programs tend to fit none.
Leadership is mostly the art of doing simple things very well.
Open yourself. Coldness congeals. Warmth heals.
The goal shouldn't be to reduce the standards for some, but to raise everyone else to the highest possible level.
Train for unity.
If you don't intend to act, then don't bother to ask if it is going on. It will only make matters worse.
I kept walking around the ship, questioning the crew, drawing them out.
Having fun with your friends creates infinitely more social glue for any organization than stock options and bonuses will ever provide.
Classroom summary techniques
A technique I use a lot when teaching/coaching is to get the participants to periodically do a summary. I have two main techniques:
The first technique (which I tend to use for smaller groups) is to ask the group to just shout out anything they can remember. Whatever they call out I write on a whiteboard and we briefly recap that topic. When the calling out slows down we stop. Then we vote; each person places three ticks on the whiteboard. I count up the ticks and we see what the top three are.
For a larger group I ask for just one thing from each person. I make it completely clear that you can choose anything you like for whatever reason you like. When someone calls something out I briefly summarize that topic but I don't write anything down.
In both cases I've found it's important not to simply ask each person, round-robin fashion, based on where they're sitting. It's much much better if you simply wait for the first person to speak, and then wait for the second person to speak, etc. That way the more confident ones naturally speak first and the less confident ones gain confidence by seeing the more confident ones go first.
The first technique (which I tend to use for smaller groups) is to ask the group to just shout out anything they can remember. Whatever they call out I write on a whiteboard and we briefly recap that topic. When the calling out slows down we stop. Then we vote; each person places three ticks on the whiteboard. I count up the ticks and we see what the top three are.
For a larger group I ask for just one thing from each person. I make it completely clear that you can choose anything you like for whatever reason you like. When someone calls something out I briefly summarize that topic but I don't write anything down.
In both cases I've found it's important not to simply ask each person, round-robin fashion, based on where they're sitting. It's much much better if you simply wait for the first person to speak, and then wait for the second person to speak, etc. That way the more confident ones naturally speak first and the less confident ones gain confidence by seeing the more confident ones go first.
Deming's knowledge of variation
Mary Poppendeick's excellent InfoQ video is online at
http://www.infoq.com/presentations/poppendieck-agile-leadership
Her summary of Deming's Knowledge of Variation at around 28 minutes is great and well worth watching.
Tandberg product development
My good friend Olve Maudal of Tandberg did a talk about Product Development in TANDBERG for the Oslo Lean Meetup. His slides are online at
http://bit.ly/cxNvjc
and are well worth a look if you care about what it takes to make world class software.
The vaccination approach to learning
Thanks to Tobias Fors for tweeting the following onto my radar.
Reading up on how learning works, I came across a couple of quotes on the subject. I particularly like the one about the vaccination approach to knowing - it exposes our fantasy that all it takes is to “send people back to school”, and then everything will be fine.
Explaining the metaphor Tobias quotes Kurt Lewin:
The learners become their own subjects and no longer objects to be filled with packages of knowledge in the manner of what Neil Postman and Charles Weingartner call the vaccination approach to knowing - “where education is something you take and, when you have taken it, you’ve had it, and if you’ve had it you are immune and need not take it again.”
2,390,000 all of a sudden
As a self-employed software coach-consultant-trainer-developer-enthusiast-etc I have to try and market myself. My marketing strategy is simple - I try to do stuff to increase my Google ranking. That's it. I monitor this by regularly typing my name into Google and seeing how many hits it generates. It's been around half a million for quite a while. I don't know why, but this morning it's suddenly jumped to over 2 million!
Skills Matter - Agile Development in C#
I'll be running Skills Matter's Agile Development in C# 3 day training course (starting March 3rd) in London. The course material is written by Kevlin Henney and is excellent. I'm really looking forward to it. Feel free to email me if you're thinking of attending.
It makes me shiver
Shiver by Natalie Imbruglia is playing. Some of the lyrics are catching my ear:
When you tell me stupid things, like you do I just have to, have to, have to, change the rules
In a rush, never trust ... if I'd only stop and take my time ... with you I'm running somewhere I can't get to
Mending a bike puncture
Ellie's bike had a puncture today. I used some tyre-levers to prise the tyre off its wheel rim. Then I carefully pulled the inner tube out and was puzzled to see a large section had folded over on top of itself! How did that happen? A hurried previous repair? I attached a pump to the valve and pumped some air into the inner tube. Then I filled a bowl of water and plunged the inner tube into the water, shifting it along section by section. Suddenly a tell-tale stream of air bubbles revealed the source of an invisible hole in the inner tube. Right in the middle of an existing patch. More evidence of a hurried previous repair. I was struck by a few thoughts
The first is that air, like software, is invisible. To get the hole to reveal itself I switched to a different medium, from air to water.
The second is the importance of root cause analysis. Find the thorn and remove it. Otherwise you'll end up patching the patch just as I did.
Drive
is the title of another excellent book by Dan Pink.
As usual I'm going to quote from a few pages:
The first ten years of this century [have been] a period of truly staggering underachievement in business, technology, and social progress.
Rewards, by their very nature, narrow our focus.
By offering a reward, a principal signals to the agent that the task is undesirable.
Mediocrity is expensive.
Consider the very notion of "empowerment". It presumes that the organization has the power and benevolently ladles some of it into the waiting bowls of grateful employees.
Management isn't the solution, it's the problem.
Effort is one of the things that gives meaning to life. Effort means you care about something, that something is important to you and you are willing to work for it. [Carol Dweck].
Being a professional is doing the things you love to do, on the days you don't feel like doing them. [Julius Erving]
In the end, mastery attracts precisely because mastery eludes.
How people spend their money may be at least as important as how much they earn [for well-being].
The Puritan Gift
is the title of an excellent book by Kenneth and William Hopper. As usual I'm going to quote from a few pages:
For a century and a half, historians have been asking themselves the chicken-and-egg question: which came first: Puritanism or Capitalism?
A system is a set of connected things or parts, bound together to a purpose.
No enemy is more terrible than money, and no friend is more trustworthy.
At the heart of the system lies mutual trust.
Given's approach was avowedly descriptive rather than prescriptive.
In spite of appearances, good decision-making is essentially the same in all walks of life.
A belief that life was not merely best understood, but also best experienced, as a struggle.
You do not own a dog and bark.
Statistics are a wonderful servant and an appalling master.
The Cult of the (so-called) Expert would severely damage the great tradition of 'generalist', 'hands-on' management.
No greater damage could be done to our economy or to our society than to attempt to 'professionalize' management by 'licensing' managers, for example, or by limiting access to management to people with a special academic degree [Peter Drucker, 1954].
I absolutely loathe the idea of professional management [Jeff Immelt, 2004].
A Whole New Mind
is the title of an excellent book by Dan Pink. As usual I'm going to quote from a few pages:
At the Yale School of Medicine, students are honing their powers of observation at the Yale Center for British Art, because students who study paintings excel at noticing subtle details about a patient's condition.
The MFA is becoming the new MBA.
Stories are how we remember.
One of the best ways to understand and develop the aptitude of Symphony is to learn how to draw.
The most creative among us see relationships the rest of us never notice.
Everything you create is a representation of something else.
Poets are our original systems thinkers.
More males than females have brains that systematize and more females than males have brains that empathize.
The people who will thrive will be those who can toggle between the two. As we've seen again and again, the Conceptual Age requires androgynous minds.
If you are laughing you cannot think. That is the objective we achieve in meditation.
People have enough to live, but nothing to live for; they have the means but no meaning.
Washroom tap psychology
Have you ever been in a washroom and failed to get any water out of a tap? Of course you have. We all have. It happens to me all the damned time.
The taps I hate the most are those stupid infra-red taps. The ones that are supposed to burst into life when you waggle your hands under them. Waggle to the left, waggle to right, in-out, in-out, doing the hokey-kokey. Your occasional random reward, if you're very lucky, is a short dribble of water.
The infra-redness is a ruse - it's fake - the tap is really part of sophisticated psychology experiment. Out of sight a white-coated clipboard-clutching technician is carefully monitoring your rising frustration. A favourite ploy is withholding water once you've dobbed a large blob of soap into your hands. And then watching as you fruitlessly search for a paper towel to wipe away the soap.
Another favourite is doctoring a clearly-full soap-dispenser into a soap-refuser. And of course, setting the force of the air-blower hand-drier to either barely-enough-to-fog-a-mirror or enough-to-lift-a-twelve-stone-man-clean-off-the-ground but never anything in between.
I miss the old-style taps.
BOYD The fighter pilot who changed the art of war
is the title of an excellent book by Robert Coram.
As usual I'm going to quote from a few pages:
He was determined to excel athough he did not yet know in what area. He only knew that he had to do something better than anyone had ever done it before.
Boyd is the only known Hun driver to work in the dangerous low-speed end of the airplane's envelope. And that was how he solved the adverse yaw problem.
They might have lost three or four pounds during the strenuous high-G maneuvers. They were thirsty and longed for a cold beer. But first they had to catch a ride on the truck that served as the flight-line taxi. They headed back to ops for the debrief, the most important part of the mission.
...more usable energy always goes into a system than comes out, because there is unavailable energy called entropy.
Tactically, the ability to quickly slow down is as important as the ability to quickly speed up.
Boyd despised optimization.
The Air Force launched a Zero Defects Campaign, and the base commander at Eglin wanted every person on base to sign a pledge saying he would make no mistakes during the coming year. Most organizations at Eglin already flew a flag saying the office was 100% FOR ZERO DEFECTS. But Boyd knew, as did almost everyone who signed the pledge, that he and everyone else would make mistakes. He thought Zero Defects was a stupid idea and refused to sign. A group of lieutenants working for Christie not only followed his lead but raised a flag that proudly proclaimed there were 100% AGAINST ZERO-DEFECTS.
Study after study shows that the higher the rank a military officer ascends, the less likely he is to make change.
You gotta challenge all assumptions. If you don't, what is doctrine on day one becomes dogma forever after.
Anything new and different is feared by a bureaucracy.
He did not become fixated on technology or "one-point" numerical solutions.
Boyd worked daily to remove things.
A twenty-pound maintenance ladder does not simply add twenty pounds to the aircraft.
Again and again they practiced.
In life there is often a roll call. That's when you will have to make a decision. To be [someone] or to do [something]? Which way will you go?
The lightweight fighter had such an extraordinary thrust-to-weight ratio and could recover energy so quickly that energy dumping became a tactic of choice rather than of desperation.
Boyd liked ambiguity.
One cannot determine the character or nature of a system within itself.
He must operate inside his adversary's time-scale.
People, ideas, hardware - in that order.
"You synchronize watches," Boyd shouted, "not people."
Another Great Week At Tandberg...
...is coming to an end. Tuesday and Wednesday I taught an Advanced C course. Thursday Olve Maudal and I did some work preparing for our Code Archeology talk at this years accu conference. I think it's going to be really great. I also had two really great pair programming sessions. I was flipping through Mary Poppendeick's Lean Software Development book and I noticed there was a page about Tandberg. She's been to Tandberg and rates it as the gold standard. I couldn't agree more. I've been fortunate enough to be asked back many times and each time I am awed by how good it is on so many levels. And then on the very next page of her book John Boyd is mentioned, which is a coincidence as I'm reading Robert Coram's book on John Boyd at the moment. I'm looking forward to the next time already.
Another C++ Unit Testing Idea
In a previous blog entry about unit-testing in C++ I wrote that instead of writing something like this...
expected = 42; actual = expression(); assert_equals(expected, actual);you could write something like this...
ARE_EQUAL(int)
{
...
expected = 42;
actual = 40+1
}
Admittedly this was not much of an improvement, if at all. However, on a flight to Oslo a few days ago I suddenly realized a way to improve it. The idea is to fold an expected == actual assertion down to this:
expected(42) == actual(40+1);Where expected and actual can be two function templates that return objects wrapping their arguments. These objects can have an overloaded == operator that does the assertion for me. Instead of emphasizing the assertion I emphasize the roles instead. Here's some proof of concept code:
#include <cassert>
#include <iostream>
template<typename T>
struct asserted_role
{
asserted_role(const char * name, const T * ptr)
: name(name)
, ptr(ptr)
{
}
const char * name;
const T * ptr;
};
template<typename T>
void failed_assertion(const asserted_role<T> & lhs,
const char * op,
const asserted_role<T> & rhs)
{
std::cout << "FAILED ASSERTION" ...
<< " " << lhs.name << "(" << *lhs.ptr << ") "
<< op
<< " " << rhs.name << "(" << *rhs.ptr << ")"
<< endl;
}
template<typename T>
void operator==(const asserted_role<T> & lhs,
const asserted_role<T> & rhs)
{
if (*lhs.ptr == *rhs.ptr)
;
else
failed_assertion(lhs, "==", rhs);
}
template<typename T>
asserted_role<T> expected(const T & t)
{
return asserted_role<T>("expected", &t);
}
template<typename T>
asserted_role<T> actual(const T & t)
{
return asserted_role<T>("actual", &t);
}
int main()
{
expected(42) == actual(40+1);
}
There are a couple of things I like about this idea. The first is I no longer have to remember to get the expected and actual in the right order; if I want to I can write:
actual(40+1) == expected(42);The second is that the idea can be extended. For example, I can create similar function templates called lesser and greater and add a < operator:
lesser(42) < greater(40+1);I can create a new template function of any name I like to express the role I'm thinking of. For example, suppose I want to test that the value of one expression is equal to the value of another expression, but neither value is "expected" or "actual" they are just two values and I don't care what the values actually are, other than the two values are equal. I can create two function templates called lhs and rhs:
lhs(2 + 2) == rhs(4);
Paloma Faith Based Development
The morning I drove into a snow-meltwater flash-food and wrote off my car - Paloma Faith was singing on the radio. The lyrics caught my ear:
The words resonate with the way some software companies are run. They close their eyes and make believe. They practice (Paloma) Faith Based Development, rather than Evidence Based Development.
Do you want the truth or something beautiful?
Just close your eyes and make believe
Do you want the truth or something beautiful?
I am happy to deceive you
The words resonate with the way some software companies are run. They close their eyes and make believe. They practice (Paloma) Faith Based Development, rather than Evidence Based Development.
British Airways - today you were RUBBISH
I use www.ba.com to book Heathrow-Oslo flights a lot. I just booked another one and accidentally specified a return day of March 20th instead of February 20th. I'm pretty careful about this kind of thing but this time I got caught out, partly because both days are a Saturday. I spotted it immediately and changed it straight away. For a flight costing £265.50 ba charged me an extra £200 which frankly I find outrageous. Their website says to ring 0844 493 0787 for help. I tried that - it's a waste of time. Endless recorded messages saying they're sorry lots of passengers have been separated from the luggage because of the snow. But no human being.
I'm reminded of something Jeff Bezos said recently - that there were two kinds of companies; those that work to charge you more, and those that work to charge you less. All my previous Heathrow-Oslo flights have been for one week. Suddenly their system was being asked for a much longer stay. It surely wouldn't take a lot of effort to get the system to spot that sudden difference and before accepting the booking simply say "we've noticed your booking is for a longer period than usual - are you sure it's correct". If their system had done that I would have been very impressed. I would have told my friends. But it didn't. Instead it charged me an extra £200.
I'm reminded of something Jeff Bezos said recently - that there were two kinds of companies; those that work to charge you more, and those that work to charge you less. All my previous Heathrow-Oslo flights have been for one week. Suddenly their system was being asked for a much longer stay. It surely wouldn't take a lot of effort to get the system to spot that sudden difference and before accepting the booking simply say "we've noticed your booking is for a longer period than usual - are you sure it's correct". If their system had done that I would have been very impressed. I would have told my friends. But it didn't. Instead it charged me an extra £200.
cyber-dojo
My vimeo submission to Jason Gorman's
Software Craftsmanship 2010 conference has sparked a little interest so I've created a
cyber-dojo github project and uploaded a an initial git repository of the rails software that drives it.
Software Craftsmanship 2010
The following is my first attempt at a submission to Jason Gorman's Software Craftsmanship 2010 conference. My submission is to run a code dojo at the conference in the alternative manner demonstrated. It's a bit rough in places, in particular the sound seems to lag the picture slightly, and I didn't set up the Ruby game instructions properly but its a start, and Jason says we're allowed to polish it during February and March anyway (which I plan to do).
Adrenaline Junkies and Template Zombies
is the title of an excellent book by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Suzanne Robertson.
As usual I'm going to quote from a few pages:
On most development projects, time is a scarcer resource than money.
Film critics believe they can be successful even if the project they are on is a failure.
Perfection is not expected; delivery is.
Whenever people get together and break rank and responsibility, the organization gets a little healthier.
Organizational lines exists for control and decision-making. They don't usually exist to accelerate work throughput.
Reality is king.
An abundance of information creates a paucity of attention.
Suppressing bad news can turn solvable problems into unsolvable problems.
The result of this misdirected civility is deep mediocrity.
Whenever you hear "I don't know," you hear a declaration of trust.
2009 AYE conference report
The 2009 AYE (Amplify Your Effectiveness) conference was started by Jerry Weinberg about 10 years ago. The conference is designed for people working in the software industry but aims to increase their effectiveness by increasing awareness at the personal and team levels.
This years conference was held at the Embassy Suites hotel in Phoenix Arizona on Nov 9th, 10th, and 11th. The weather was hot and sunny as you'd expect in a desert city. The hotel is clean and spacious and air conditioned, the rooms likewise, and the staff friendly and helpful. It has a large heated outdoor pool with an accompanying jacuzzi, a spacious veranda area and an open-tent area for eating outdoors.
I've read that Jerry started the conference to win a bet he made whilst attending another conference he was not impressed with. It's therefore not too surprising that anything remotely resembling a powerpoint presentation is banned and always has been. Instead the conference emphasizes simulation and experience. The website at http://www.ayeconference.com/ contains a wiki full of material spanning many years and is well worth a look if you are interested in attending.
Each participant's name badge revealed their Myers Briggs personality type (you are asked to do an online test before you arrive). This provided an interesting topic of conversation but was only very lightly used during the scheduled sessions. Many of the sessions were role play type games, typically organized into teams.
The conference is limited to 80 participants on a first come first served basis. $300 dollars reserved a space and the total cost depended on how early you paid in full (reserve later and its dearer). Paying at the earliest opportunity meant another $900 to pay. Plenty of drink and snacks are provided together with a buffet style midday meal. On top of this the hotel room costs about $100 a night which includes an excellent breakfast. Add to this an evening meal and the flight.
The conference felt a lot like a non-technical version of the ACCU conference. It had a very relaxed atmosphere and yet at the same time was quite intense at times. I really enjoyed it and found it a very valuable experience. I met lots of great people and plan to attend in 2010.
This years conference was held at the Embassy Suites hotel in Phoenix Arizona on Nov 9th, 10th, and 11th. The weather was hot and sunny as you'd expect in a desert city. The hotel is clean and spacious and air conditioned, the rooms likewise, and the staff friendly and helpful. It has a large heated outdoor pool with an accompanying jacuzzi, a spacious veranda area and an open-tent area for eating outdoors.
I've read that Jerry started the conference to win a bet he made whilst attending another conference he was not impressed with. It's therefore not too surprising that anything remotely resembling a powerpoint presentation is banned and always has been. Instead the conference emphasizes simulation and experience. The website at http://www.ayeconference.com/ contains a wiki full of material spanning many years and is well worth a look if you are interested in attending.
Each participant's name badge revealed their Myers Briggs personality type (you are asked to do an online test before you arrive). This provided an interesting topic of conversation but was only very lightly used during the scheduled sessions. Many of the sessions were role play type games, typically organized into teams.
The conference is limited to 80 participants on a first come first served basis. $300 dollars reserved a space and the total cost depended on how early you paid in full (reserve later and its dearer). Paying at the earliest opportunity meant another $900 to pay. Plenty of drink and snacks are provided together with a buffet style midday meal. On top of this the hotel room costs about $100 a night which includes an excellent breakfast. Add to this an evening meal and the flight.
The conference felt a lot like a non-technical version of the ACCU conference. It had a very relaxed atmosphere and yet at the same time was quite intense at times. I really enjoyed it and found it a very valuable experience. I met lots of great people and plan to attend in 2010.
Agile Coaching
Coaches work one step at a time rather than creating a whirl-wind of change.
Patience is one of the most important qualities of a coach.
We find the hardest part of listening is resisting the temptation to jump in too early with advice or to switch the conversation to a similar story that happened to you.
People usually speak much slower than you can think, which is why it is so hard to give your full attention when someone else is talking.
You have to do more than suggest a course of action for people to follow it. You need to lead the way by explaining why it's important and then show them how to get started with it.
Your focus is process improvement, not individual performance.
Each change they adopt reduces their resistance to the next change.
Take care not to ask questions when you actually want to give guidance.
When people start caring only about their own tasks, teamwork starts to break down.
Useful information should be visible to all and not hidden away in computers. Plans kept electronically are information fridges; they give up their information only when they are opened.
Quality Software Management
Vol 2. First-Order Measurement
is the title of an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
Software development is not primarily a manufacturing operation for we (ideally) never develop the same software twice. This uniqueness of product means that Deming's "statistical signal" - though necessary - is not sufficient for feedback control, because there often isn't enough repetition - enough stability - to generate meaningful statistics.
In software we are attempting to obtain value by achieving higher precision than human beings have ever attempted before.
The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 (Routine) to Pattern 3 (Steering).
Under emotional pressure, people literally stop thinking.
A fact becomes a feeling as soon as you observe it.
The triad has special significance for observation, because it is the first grouping in which there is both interaction and observation of interaction.
The way I remember the difference between faults and failures is to think of earthquakes. Faults (in the ground) leads to failures (in bridges, buildings, and so forth).
One of the most sensitive measures of the cultural pattern of any organization is how quickly it finds and removes problems.
Any plan is just a plan - a series of guesses about how the future will work out.
Bureaucracy: people doing things whose purpose they don't understand.
Jonathan Livingston Seagull
is the title of an excellent book by Richard Bach. It's well worth rereading every year or so. As usual I'm going to quote from a few pages:
...to eat, to stay alive as long as we possibly can.
Jonathan Seagull discovered that boredom and fear and anger are the reasons that a gull's life is so short, and with these gone from his thought, he lived a long life indeed.
We choose our next world through what we learn in this one.
Heaven is not a place, and it is not a time. Heaven is being perfect.
You have less fear of learning than any gull I've seen in ten thousand years.
"Why is it", Jonathan puzzled, "that the hardest thing in the world is to convince a bird that he is free, and that he can prove it for himself if he'd just spend a little time practising? Why should that be so hard?
You don't love hatred and evil, of course. You have to practise and see the real gull, the good in every one of them, and to help them see it in themselves.
Don't believe what your eyes are telling you. All they show is limitation. Look with your understanding, to find out what you already know, and you'll see the way to fly.
Shadow Data Types
This article appeared in the December 2009 issue of the accu Overload magazine.
Shadow Data Types
Suppose we have a type called wibble defined as a concrete data type (that is, a type whose representation is fully visible) as follows:// wibble.h
#include "grommet.h"
#include "flange.h"
typedef struct
{
grommet g;
flange f;
} wibble;
void wopen(wibble * w, int i);
...
void wclose(wibble * w);
The definition of wibble exposes the types involved in its
representation (grommet and flange in this made up example), and hence
requires a #include for those types in its header file. This exposure
has a price. One cost is that any change to the grommet or flange
header files, or any header files they in turn #include, at any depth,
will require a recompilation of any source file that #includes wibble.h
(either directly or transitively). Another cost is that client code can
easily become reliant on the exposed representation rather than relying
solely on the functional api. Note that in C++ you can avoid this
problem by declaring your data members private.
Abstract Data Types
These costs are sufficiently high that software developers have invented techniques to hide a type's representation; to turn a type into an Abstract Data Type. An Abstract Data Type is simply a type that does not reveal its representation; a type that abstracts away its representation. In this article I'll look at two abstract data type implementation techniques: Opaque Data Types, and Shadow Data Types.Opaque Data Types
The term Opaque Data Type is a well established term for the technique of exposing only the name of the type in its header file. This is done with a forward type declaration. This certainly has the affect of not exposing any representation!// wibble.h typedef struct wibble wibble; wibble * wopen(int); ... void wclose(wibble *);
Storage class restrictions
A definite downside with this approach is that clients cannot create objects.#include "wibble.h"
void eg(void)
{
wibble * ptr; // ok
wibble value; // constraint violation
ptr = malloc(sizeof *ptr); // constraint violation
}
The wibble type's representation is defined in its source file and
so only code
in the source file can create wibble objects. Furthermore, these wibble
objects have to be returned to users as pointers. These two constraints
mean the created objects cannot have auto storage class. This is a
great loss since auto storage class alone of the three storage class
options allows the clients to decide where the objects live which can
greatly improve locality of reference.
// wibble.c
...
wibble * wopen(int value)
{
wibble opened;
...
return &opened; // very very bad
}
...
A second possibility is to create the objects with static storage class:
// wibble.c
...
static wibble wstorage[42];
static size_t windex = 0;
...
wibble * wopen(int value)
{
wibble * opened = &wstorage[windex];
windex++;
...
return opened;
}
...
The final possibility is to create the objects with allocated storage class. That is,
to create the objects dynamically on the heap:
// wibble.c
...
wibble * wopen(int value)
{
wibble * opened = malloc(sizeof *opened);
...
return opened;
}
...
The static and the allocated approaches have opposing advantages and disadvantages.
Static storage is very fast and doesn't fragment the memory but the type has to decide
the maximum number of objects the application will need. That might be a dependency going in the wrong direction.
Allocated storage is much slower and can create memory fragmentation issues, but
the application decides how many objects it needs.
In short, the classic ADT technique creates an abstraction that is
very opaque and pays a hefty price for this "over-abstraction".
Abstracting away the representation also abstracts away the size
details of a type and it is the loss of the size information that
creates the storage class restrictions.
The Shadow Data Type implementation technique attempts to rebalance
these forces of abstraction by separating size abstraction from representation abstraction.
Shadow Data Types
The term Shadow Data Type, in contrast to Opaque Data Type, is not a well established term. The technique I'm calling Shadow Data Type has probably been around for a long time, it's just that it doesn't seem to have ever been documented anywhere and so a term for it has never become established. I've chosen the term Shadow Data Type to try and convey the idea that when you shine a light on an object it casts a shadow which reveals something of the size of the object but nothing of the details of the object. In other words, a Shadow Data Type has a "full" type declaration (rather than a forward type declaration) but one revealing only the size of type.// wibble.h
typedef struct
{
unsigned char size_shadow[16];
} wibble;
void wopen(wibble *, int);
...
void wclose(wibble *);
The "true" definition of the type (together with its accompanying #includes) moves into the source file:
// wibble.c
#include "wibble.h"
#include "grommet.h"
#include "flange.h"
#include <string.h>
typedef struct
{
grommet g;
flange f;
} wibble_rep;
// sizeof(wibble) >= sizeof(wibble_rep)
void wopen(wibble * w, int value)
{
wibble_rep rep;
...
...
memcpy(w, &rep, sizeof rep);
}
...
However, there are two problems needing attention.
Synchronized Alignment?
Firstly, there is no guarantee the two types (wibble and wibble_rep) are alignment compatible. We can solve this problem. The trick is to create a union containing all the basic types. We don't know which basic types have the strictest alignments but if the union contains them all the union must also have the strictest alignment.// alignment.h
typedef union
{
// one of each of all the basic types go here
// including data pointers and function pointers
} alignment;
We redefine wibble to be a union with two members; one member to take care of the
memory footprint and one member to take care of the alignment:
// wibble.h
#include "alignment.h"
typedef union
{
unsigned char size_shadow[16];
alignment universal;
} wibble;
...
The main problem with wibble being a union is that unions are rare.
Suppose you want to forward declare the wibble type in a header. You're
quite likely to forget it's a union.
typedef struct wibble wibble; // OooopsWe can fix this by simply putting the union inside a struct!
// wibble.h
#include "alignment.h"
typedef struct
{
union
{
unsigned char size[16];
alignment universal;
} shadow;
} wibble;
...
This is now sufficiently tricky to warrant an abstraction of its own:
// shadow_type.h
#ifndef SHADOW_TYPE_INCLUDED
#define SHADOW_TYPE_INCLUDED
#include "alignment.h"
#define SHADOW_TYPE(name, size) \
typedef struct \
{ \
union \
{ \
unsigned char bytes[size]; \
alignment universal; \
} shadow; \
} name
#endif
// wibble.h #include "shadow_type.h" SHADOW_TYPE(wibble, 16);
Synchronized Size?
The second problem is hinted at by the comment in wibble.c// sizeof(wibble) >= sizeof(wibble_rep)This comment, like all comments, has no teeth. Ideally we'd like an assurance that if the types' sizes lose synchronization we're told about it. This can be done by asserting the relationship inside a unit test of course. The problem with this the possibility that the runtime check inside a unit-test won't get run. Or, more likely, that the unit-test simply won't get written at all. Fortunately in this case we can check the relationship using a compile time assertion. We start with the fact that you cannot declare an array of negative size:
extern char wont_compile[-1]; extern char will_compile[+1];Now we have to select a size of either +1 or -1 if the asserted expression is true or false respectively.
// may or may not compile extern char compile_time_assert[sizeof(wibble) >= sizeof(wibble_rep) ? +1 : -1];Hiding this mechanism behind a macro inside a dedicated header helps to make the code more Intention Revealing.
// compile_time_assert.h #define COMPILE_TIME_ASSERT(description, expression) \ extern char description[ (expression) ? 1 : -1 ]
// wibble.c ... #include "compile_time_assert.h" ... COMPILE_TIME_ASSERT(sizeof_wibble_is_not_less_than_sizeof_wibble_rep, sizeof(wibble) >= sizeof(wibble_rep)); ...It's worth spending a few moments to think about alignment carefully. The wibble type contains a union to give us the strictest alignment. This means a single wibble_rep and a single wibble can overlay each other in either direction. If we create an array of wibbles the compiler will ensure the address of each wibble is suitably aligned. To do this it may add trailing padding to the wibble type but this padding will be reflected by sizeof(wibble). Similarly, any padding for the wibble_rep type will also be reflected by sizeof(wibble_rep). Importantly, since sizeof(wibble_rep) may be strictly less than sizeof(wibble) we cannot overlay an array of either type directly onto an array of the other type. However, we are only concerned with creating an array of wibbles since that is the type the client uses. There should never be any need to create an array of wibble_reps. Nevertheless, the .c file implementation must always do any array pointer arithmetic in terms of wibbles and never in terms of wibble_reps. Note also that using >= rather than == also allows binary compatibility with any alternative smaller representation.
Casting the shadow
Inside the source file we can create a helper function to overlay the true representation onto the clients memory (the fragment below uses the dot designator syntax introduced in c99):// wibble.c
static inline void shadow(wibble * dst, wibble_rep * src)
{
memcpy(dst, src, sizeof *src);
}
bool wopen(wibble * w, const char * name)
{
wibble_rep rep =
{
.g = ...,
.f = ...,
};
shadow(w, &rep);
...
}
Careful use of memcpy can help to make the wibble functions behave atomically from the users perspective. That is to say, the function can do the work off to the side in a local wibble_rep, and copy
back into the shadow only if everything is successful.
An alternative to memcpy is to cast the pointer on each access:
// wibble.c
static inline wibble_rep * light(wibble * w)
{
return (wibble_rep *)w;
}
void wclose(wibble * w)
{
wibble_rep * rep = light(w);
rep->g = ...;
rep->f = ...;
...
}
Constness?
It makes no sense to declare a wibble object with a const modifier unless the object can be initialized.void pointless(void)
{
const wibble w; // :-(
// ... ?
}
However, this is not an issue since the wibble type is opaque anyway.
Nevertheless, a slight redesign can accommodate const wibble
objects if desired, at the cost of copying struct objects:
...
wibble wopen(int value)
{
wibble_rep rep = { ...value... };
wibble w;
memcpy(&w, &rep, sizeof rep);
return w;
}
void ok(void)
{
const wibble w = wopen(42);
...
}
Summary
In C it is impossible to expose a type's size without also exposing its representation. It is possible to define a type concretely and to explicitly specify its representation as being "unpublished". However, since C does not offer the C++ private keyword using the representation is always possible and remains a constant temptation. Once one piece of client code succumbs more are sure to follow and like a dam bursting the client and implementation quickly become tightly coupled and any separation is washed away. Completely hiding a type's representation behind an opaque pointer/handle removes the temptation and creates a powerful abstraction but at the price of hiding the size of the type and the consequent restriction on the storage class of client memory. A shadow data type offers a half-way house where a type is effectively split into two, with one part exposing the size and the other part holding the representation. The alignment and sizes of the two parts must correspond. Client code is then able to use all three storage class options. The implementation code takes the full load of the extra complexity mapping/overlaying between the split parts. One interesting observation is that the client code would be uneffected (other than needing recompilation) if the representation was moved back into the client side type (to try and improve performance perhaps). No mechanism is universally applicable and the shadow data type is no exception! Experience and time alone will tell if and how useful it is. Caveat emptor.
Perfect Software and other illusions about testing
is the title of an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
Information is neutral but people's reactions to information are rarely neutral.
I'm not in the proof business; I'm in the evidence and inference business.
A process description is just that, a description ... not of what has actually been done.
To qualify as a test, an action has to seek information that will influence an action.
Fixing under pressure tends to raise the fault-feedback-ratio.
Anyone who makes promises about the future must be some sort of devil.
Errors are made, not born.
In a moment of weakness it is difficult to resist infantile suggestions.
Good tools amplify effectiveness; if your effectiveness is negative, adding tools will amplify only the negativity.
enums in C
Enums are notoriously weakly typed in C. While pondering this the other day it occurred to me that instead of writing an enum like this:
enum suit { clubs, hearts, diamonds, spades };
you could write it like this:
struct suit
{
enum { clubs, hearts, diamonds, spades } value;
};
The struct wrapper adds a modicum of type safety. It also allows you to forward declare suit (you can't forward declare enums). The enumerators (clubs, hearts, diamonds, clubs) are still visible and can be used when a compile time value is required (e.g., switch cases). As usual, caveat emptor.
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.
BOSE - today you were RUBBISH
I bought a pair of BOSE noise canceling headphones at Oslo airport on 29th August. My first BOSE purchase. The left earphone has stopped working. I rang the service number and briefly explained the situation. The assistant asked for some information, some of which I'd just told her. She typed into a computer and her computer crashed. She didn't know what to do so she put me on hold. While I waited I replied to a couple of emails, made an entry to my wiki, and started reading from a book. Then she was back. She apologised. She told me that everyone's computer has crashed! She asks me for the information again. I provide it again. She types it in again. It doesn't crash this time!
Then she asks for the serial number. "Where is that?" I say. "What kind of headphones have you bought?" she says. "How can I tell?" I say. It seems you can't tell by looking at them - they have a minimalist design with only the words BOSE on the headphones. "Try looking inside the ear cushion" she says. I can see a number in the left one. I start reading it out. "No that's not it". Eh? You have a serial number in both earphones but only one is the actual one? Are you trying to be rubbish I wonder. So I look in the other ear cushion. Indeed - another number. So long and so small I can't read it. So I put my glasses on and read it out. "Ah" she says that's the such-and-such model. "They're discontinued". Why am I not surprised. She can't do a like for like replacement for that. So they'll replace it with the nearest equivalent. But before they can do that they'll post me an audio cable - could I try the new cable to see if that fixes it? it will be delivered in 5-7 working days, all I have to do is sign for it. If I'm not in when they deliver it they'll put a note through the door so I know which depot to drive to pick them up from. By now I'm losing my patience. I ask if she's really telling me I'm going to have to stay in all day to receive an audio cable that in all probability won't solve my problem and is merely creating extra weeks when I have no working BOSE headphones despite having paid over £200 for them only 2 months ago? And besides that I won't be in anyway since I'll be in another country on business. On business without my BOSE headphones. She says she'll ask someone. I'm on hold again. No, she was wrong. They'll send them regular post. They don't have to be signed for. She's very sorry but there's nothing else she can do. That's what she has to do. I'm so fed up with BOSE at this point I can't face wasting anymore of my time so I tell her to send the damn audio cable.
Do BOSE think that people willing to pay £200 for a supposed quality pair of headphones value their time so little that they're happy to waste even more of it just because the headphones don't work?
BOSE products are expensive. They are pitched as high quality products. My experience today tells me their customer service computers and their customer service process is not high quality. I don't in any way blame the girl on the phone. She's trapped inside a rubbish system, forced to follow rigid procedures like a robot.
BOSE, today you were RUBBISH.
Then she asks for the serial number. "Where is that?" I say. "What kind of headphones have you bought?" she says. "How can I tell?" I say. It seems you can't tell by looking at them - they have a minimalist design with only the words BOSE on the headphones. "Try looking inside the ear cushion" she says. I can see a number in the left one. I start reading it out. "No that's not it". Eh? You have a serial number in both earphones but only one is the actual one? Are you trying to be rubbish I wonder. So I look in the other ear cushion. Indeed - another number. So long and so small I can't read it. So I put my glasses on and read it out. "Ah" she says that's the such-and-such model. "They're discontinued". Why am I not surprised. She can't do a like for like replacement for that. So they'll replace it with the nearest equivalent. But before they can do that they'll post me an audio cable - could I try the new cable to see if that fixes it? it will be delivered in 5-7 working days, all I have to do is sign for it. If I'm not in when they deliver it they'll put a note through the door so I know which depot to drive to pick them up from. By now I'm losing my patience. I ask if she's really telling me I'm going to have to stay in all day to receive an audio cable that in all probability won't solve my problem and is merely creating extra weeks when I have no working BOSE headphones despite having paid over £200 for them only 2 months ago? And besides that I won't be in anyway since I'll be in another country on business. On business without my BOSE headphones. She says she'll ask someone. I'm on hold again. No, she was wrong. They'll send them regular post. They don't have to be signed for. She's very sorry but there's nothing else she can do. That's what she has to do. I'm so fed up with BOSE at this point I can't face wasting anymore of my time so I tell her to send the damn audio cable.
Do BOSE think that people willing to pay £200 for a supposed quality pair of headphones value their time so little that they're happy to waste even more of it just because the headphones don't work?
BOSE products are expensive. They are pitched as high quality products. My experience today tells me their customer service computers and their customer service process is not high quality. I don't in any way blame the girl on the phone. She's trapped inside a rubbish system, forced to follow rigid procedures like a robot.
BOSE, today you were RUBBISH.
Becoming a Technical Leader
is the title of an excellent book by Jerry Weinberg.
As usual I'm going to quote from a few pages:
Underlying organic models is the fundamental idea of systems thinking: "It is impossible to change just one thing at a time."
Leaders are leaders of change in themselves.
People don't become leaders because they never fail. They become leaders because of the way they react to failure.
If you are a leader, people are your work.
There is no conflict between people and task.
Doing something new heightens awareness, which is stimulating, but also a little uncomfortable.
If you intend to grow you cannot avoid some pain.
Very few of the classic leadership studies have been done in environments even vaguely resembling the technical work situation.
The only way we can see ourselves is through other people. This inability to see ourselves as others see us is the number one obstacle to self-improvement.
Becoming a leader means shifting the focus from your ideas to the ideas of others.
30 Great Systems Thinkers
Systems Thinkers is a book by Magnus Ramage and Karen Shipp which has just caught my eye. The blurb on Amazon says:
Annoyingly it doesn't mention who the 30 people are. A bit of googling reveals the missing information:
Early Cybernetics
General Systems Theory
System Dynamics
Soft and Critical Systems
Later Cybernetics
Complexity Theory
Learning Systems
Systems Thinkers presents a biographical history of the field of systems thinking, by examining the life and work of thirty of its major thinkers.
Annoyingly it doesn't mention who the 30 people are. A bit of googling reveals the missing information:
Early Cybernetics
- Gregory Bateson
- Norbert Wiener
- Warren McCullough
- Margaret Mead
- W. Ross Ashby
General Systems Theory
- Ludwig von Bertalanffy
- Kenneth Boulding
- Geoffrey Vickers
- Howard Odum
System Dynamics
- Jay Forrester
- Donella Meadows
- Peter Senge
Soft and Critical Systems
- C. West Churchman
- Russell Ackoff
- Peter Checkland
- Werner Ulrich
- Michael Jackson
Later Cybernetics
- Heinz von Foerster
- Stafford Beer
- Humberto Maturana
- Niklas Luhmann
- Paul Watzlawick
Complexity Theory
- Ilya Prigogine
- Stuart Kauffman
- James Lovelock
Learning Systems
- Kurt Lewin
- Eric Trist
- Chris Argyris
- Donald Schön
- Mary Catherine Bateson
Whole > Sum(Parts)
I was chatting to my friend Mark today. He's retired and spends his time doing exactly what he wants to which is mostly making tools and using them to make more tools and lots of beautiful things. Today he was showing me his newly finished rose cutter which allows him to create wood turning patterns you wouldn't think possible. Anyway, at one point we were chatting about shooting rabbits. He mentioned that making a gun was easy, a couple of evening's work he said! Making ammunition was more tricky though. He said you can buy all of the separate bits you need to make bullets without a license. But when you put them together then you need a license and face a jail sentence if you haven't got one. I thought was a nice example of the whole being greater than the sum of the parts.
A Tale of Two Sessions
I attended this years excellent AYE conference in Phoenix. Powerpoint style presentations are not allowed at AYE; many session are instead based on simulation and role-playing led by an experienced facilitator.
The two sessions I attended on the Wednesday remain in my thoughts. Don Gray led the morning session and Steve Smith led the afternoon session. The task in both sessions was broadly similar (sorting decks of cards), but the contrast between the two sessions could hardly have been greater.
Don added arbitrary time pressure as part of the game and the participants accepted it. Steve's exercise had no time pressure. Well actually that's not quite true. I think there was time pressure but Obie who played the role of Steve's project manager shielded the workers from it very effectively. The feeling of being rushed was palpable in Don's session, whereas a feeling of general calm pervaded Steve's. There was a noticeable difference in the noise levels!
Don's exercise was initially more or less impossible to complete because of some confusion and contradiction in the requirements (quite possibly deliberate). The requirements seemed to be in much greater state of flux and quite a few participants (me included) sensed this and asked the customers various questions. This didn't help. In Steve's exercise Obie again did an excellent job of keeping things simple for the customer and the workers by being the only point of contact between them.
In Steve's session Obie explicitly said to the workers that if they didn't have anything to do at some point that was ok, they should just step back, observe and try to see where they could help. They should try not to interfere. This helped to emphasize the primary importance of the team and the overall goal.
In Don's session some people sensed the chaos building up and tried to intervene individually to help. It didn't help. All it served to emphasize was individual action rather than team co-operation. In Steve's session there was never a sense of chaos and any time any problems arose the participants were generally much more willing to follow a direction for the good of the team. They may not have agreed with the direction but you don't have to agree with a direction to support it as if it were your own. Following can often be a powerful act of leadership.
There were roughly the same number of people participating in both sessions. However, in Don's session several people disengaged from the exercise precisely because it was so chaotic. They were experiencing real discomfort. In its own way this too was an act of leadership - by removing themselves from the game they created a much better chance for the smaller team to overcome the chaos.
Don added arbitrary time pressure as part of the game and the participants accepted it. Steve's exercise had no time pressure. Well actually that's not quite true. I think there was time pressure but Obie who played the role of Steve's project manager shielded the workers from it very effectively. The feeling of being rushed was palpable in Don's session, whereas a feeling of general calm pervaded Steve's. There was a noticeable difference in the noise levels!
Don's exercise was initially more or less impossible to complete because of some confusion and contradiction in the requirements (quite possibly deliberate). The requirements seemed to be in much greater state of flux and quite a few participants (me included) sensed this and asked the customers various questions. This didn't help. In Steve's exercise Obie again did an excellent job of keeping things simple for the customer and the workers by being the only point of contact between them.
In Steve's session Obie explicitly said to the workers that if they didn't have anything to do at some point that was ok, they should just step back, observe and try to see where they could help. They should try not to interfere. This helped to emphasize the primary importance of the team and the overall goal.
In Don's session some people sensed the chaos building up and tried to intervene individually to help. It didn't help. All it served to emphasize was individual action rather than team co-operation. In Steve's session there was never a sense of chaos and any time any problems arose the participants were generally much more willing to follow a direction for the good of the team. They may not have agreed with the direction but you don't have to agree with a direction to support it as if it were your own. Following can often be a powerful act of leadership.
There were roughly the same number of people participating in both sessions. However, in Don's session several people disengaged from the exercise precisely because it was so chaotic. They were experiencing real discomfort. In its own way this too was an act of leadership - by removing themselves from the game they created a much better chance for the smaller team to overcome the chaos.
When technology pisses me off (5)
I went into my local Orange shop today. I simply wanted to upgrade my phone to one with a higher resolution camera. The assistant asked me some details and typed them into a computer. Nothing happened. She asked a colleague if the computer was working. He said try rebooting it. So she did. Then she asked me the same details again. And typed them in again. Still not working. Long pause with nothing happening. Decided not to get frustrated. Looked for a chair to sit down while I waited. No chairs. Sat on a low shelf instead. She asked me for the same details for a third time. This time I wrote them on a piece of paper. I decided to mention something I hadn't been asked - that I was on the Virgin tariff. That seemed to be an important piece of information and the computer was abandoned as she tried to ring someone for help. She couldn't get through. I went to sit down again. She kept trying. Eventually she got through. She passed the phone to me. The man on the other end asked for the same information for a fourth time. Then he asked me the post code of the shop I was in! I remained calm and handed the phone back to the assistant. I sat down again. The call ended. After all that I was told I couldn't upgrade my phone unless I switched to a different tariff. I was near the end of my tether by this point but I decided to at least look at the new tariffs. All more expensive than the one I'm one. I said simply "It's not going to happen. You've lost a sale." and walked out. Orange - today you were RUBBISH.
#exclude - a testing idea for C/C++
Suppose you're working on a legacy C/C++ codebase and you want to introduce some characterization tests. One seam you might consider exploiting is #includes. It's quite easy to exclude includes. For example:
# excluder.rb
include = Regexp.new('(\s*)#(\s*)include(.*)')
STDIN.readlines.each do |line|
if include.match(line)
line = "#if 0\n" + line + "#endif\n"
end
STDOUT.write line
end
This small Ruby program reads in a source file and writes out the same source file, except the #includes are commented out. Each line like this:
#include <stdio.h>is replaced like this:
#if 0 #include <stdio.h> #endifThis enables you to create an "isolated" version of a source file. One where all the dependencies arising from the #includes, to any depth, are slashed in one swift cut. One where your tests clearly and visibly have to recreate all those dependencies in a custom mock environment.
This is just an idea. I might not be a good idea. I only thought of it last week. Caveat emptor.
Incomplete types oddity in C
Here's something odd from C. It's to do with incomplete types. This compiles fine in gcc:
This suggests the [] based declarator is ok. However it's not because...
Which leads you ask what is an incomplete type?
Which is interesting because it says nothing about an array of unknown type being an incomplete type. This is a shame. Particularly because of the new [] array declarator syntax in c99.
typedef struct wibble wibble; void f(wibble * ptr);but this does not:
typedef struct wibble wibble; void f(wibble array[]);A bit of searching in the Standard reveals
6.7.5.3 Function declarators
paragraph 12 - If the function declarator is not part of a definition of that function, parameters may have incomplete types...
This suggests the [] based declarator is ok. However it's not because...
6.7.5.2 Array declarators
paragraph 1 - the element type shall not be an incomplete type
Which leads you ask what is an incomplete type?
6.2.5 Types
paragraph 22 - An array of unknown size is an incomplete type.
Which is interesting because it says nothing about an array of unknown type being an incomplete type. This is a shame. Particularly because of the new [] array declarator syntax in c99.
Showers are lean-agile; baths are not
In the shower a few days ago I realized that showering vs bathing is a nice example of being lean-agile or not. Imagine 10 people bathing sequentially vs showering sequentially...
With a bath you have to wait (in a queue) while the bath fills up. Not so with a shower.
If you do something else while you wait for the bath to fill up you're likely to find the bathwater too hot or too cold.
Or the tap turns itself off (I have a hot tap that does that sometimes) and the bath is still virtually empty.
Or that might be the time you discover the overflow pipe is blocked.
Or that a fully-on tap releases water faster than an overflow pipe can drain it.
With a bath the water stays in the bath and gets dirty.
With a bath the water gets cold as you lie in it.
With a bath you have to drain the water before you can refill it so the next person can bath in clean water.
With a bath you use more water.
A bath takes up more floor space.
In a shower you stand up, you stay more awake.
A bath is less encapsulated.
Bath leaves a ring of scum that has to be cleaned.
Birth of the chaordic age
is the title of an excellent book by Dee Hock. As usual I'm going to quote from a few pages:
All things, even life itself, are a seamless blending of chaos and order.
By structure I mean the embodiment of purpose, principles, people, and concept.
The results of the best organizations are apparent, but the structure, leadership, and process and transparent.
Information multiplies by transfer and is not depleted by use.
Knowledge becomes understanding when related to other knowledge in a manner useful in conceiving, anticipating, evaluating, and judging. Understanding becomes wisdom when informed by purpose, ethics, principles, memory of the past, and projection into the future.
All knowledge is an approximation.
The information age is primarily an extension of mental power.
We are at that very point in time when a four-hundred-year-old age is rattling in its deathbed and another is struggling to be born.
Out of Our Minds
is the title of an excellent book by Ken Robinson. As usual I'm going to quote from a few pages:
People are not creative in general but in doing something concrete.
Spontaneity sometimes has to be carefully planned.
Creativity is not just a matter of letting go: it involves hanging on.
Creativity is as much a process of finding problems as solving them.
Trying to put some experiences into words is like stringing clothes on a washing line when in practice they are worn one inside the other.
Creativity is a process not an event.
We classify at our peril.
Creativity is incremental.
Creativity relies on the flow of ideas.
Important - do not rub off
In one of his books Jerry Weinberg mentions a cleaner who wasn’t allowed to wipe the whiteboards. The story conjures familiar images of whiteboards full of stuff labeled “important - do not rub off”. It’s likely the stuff has lain untouched on that no-longer-white-whiteboard for weeks or months. It’s no longer important but there it stays, filling the whiteboard. A whiteboard full of stuff discourages its use in exactly the same way an empty whiteboard encourages it. And a whiteboard with the words “important - do not rub off” positively discourages use. It's really saying "keep away".
The whole purpose of whiteboards is that you wipe them. Perhaps they should be called wipeboards! Buying a wipeboard and its special pens and its special erasers and then filling it with stuff just the once is silly and expensive. If you want something permanent why not use a permanent pen on a big piece of paper stuck to the wall?
Filling a wipeboard with stuff labeled “important - do not rub off” is also silly if the stuff genuinely is still important. Someone might be desperate for a wipeboard and decide their new definitely-important stuff is more important than somebody else’s existing possibly-important stuff. So they wipe it. Wipeboards are so easy to wipe after all!
Le Chatelier's Principle says "[good] systems tend to oppose their own proper function". What is the proper function of a wipeboard? To be written on. How do you oppose being written on? Simple - wipe them completely clean every so often. Ruthlessly. Even if someone's written "important - do not rub off" on them.
With this use-clean use-clean use-clean dynamic set up the wipeboards give a clear visual impression of their dynamic use since anything on a wipeboard must necessarily have be written fairly recently. If they remain mostly unused most of the time you get to see that very clearly too.
Le Chatelier's Principle revisited
I was chatting about Le Chatelier’s principle with Hubert Matthews at an accu meeting in London yesterday evening. Hubert is a very smart guy and explained to me that losing your boarding card is a nice example, but not necessarily of Le Chatelier’s principle. What did I misunderstand?
Le Chatelier’s principle says "systems tend to oppose their own proper function". I incorrectly read this as a description of a poor system, an unorganized system, a system with no feedback, no control, (you get the idea), a system straying further and further out of balance at the slightest touch. In other words the system opposes its own proper function - but only in the sense that it never really had a chance of functioning properly in the first place! A system likely to die a quick natural death. That was the kind of systems behaviour I was looking for a name for. But I’ll come back to that.
So what is Le Chatelier’s principle really saying? As always an example helps. Every cell in your body requires a constant supply of glucose for energy. If your blood sugar level rises (e.g. after a meal) special cells in your pancreas produce insulin. Insulin causes the liver and muscles convert the extra glucose to glycogen and store it away, helping to reduce blood sugar levels. This is normal functioning. This is proper function. Ok. Now, what Le Chatelier’s Principle says (assuming I've got it right this time) is that your body will oppose this proper function! And your body does indeed start this opposition, and for a very good reason – if the insulin is left unchecked it continues to drain glucose from the blood and your blood sugar level gets too low. So when this happens different special cells in the pancreas start to produce glucagon. The glucagon works in opposition to insulin, causing the liver and muscles to convert the stored glycogen back into glucose thus increasing your blood sugar level.
In a healthy person these mini-systems operate quite properly, just like a thermostat, keeping your blood sugar level safely between fairly strict limits. Not too much (hyperglycemia) and not too little (hypoglycemia). They do this by opposing each other. It reminds me of the Goldilocks Principle. Goldilocks didn’t like the bed too soft or too hard, or the porridge too hot or too cold. Goldilocks knew her own mind.
So what have I learned from this? I’ve learned that I understand Le Chatelier’s Principle a bit better if I reword it ever so slightly to start with the word good. Good is a bit weak but I’m a bit pushed for time so it will do for now.
So what is my boarding card example an example of? Does The Inverse Le Chatelier’s principle apply? If a system does not oppose its own proper function is it more likely to be a poor system? I think there's an element of truth to that. If so we have Le Chatelier’s Principles. There are two of them, in opposition to each other, which somehow feels appropriate!
Thanks Hubert.
Le Chatelier’s principle says "systems tend to oppose their own proper function". I incorrectly read this as a description of a poor system, an unorganized system, a system with no feedback, no control, (you get the idea), a system straying further and further out of balance at the slightest touch. In other words the system opposes its own proper function - but only in the sense that it never really had a chance of functioning properly in the first place! A system likely to die a quick natural death. That was the kind of systems behaviour I was looking for a name for. But I’ll come back to that.
So what is Le Chatelier’s principle really saying? As always an example helps. Every cell in your body requires a constant supply of glucose for energy. If your blood sugar level rises (e.g. after a meal) special cells in your pancreas produce insulin. Insulin causes the liver and muscles convert the extra glucose to glycogen and store it away, helping to reduce blood sugar levels. This is normal functioning. This is proper function. Ok. Now, what Le Chatelier’s Principle says (assuming I've got it right this time) is that your body will oppose this proper function! And your body does indeed start this opposition, and for a very good reason – if the insulin is left unchecked it continues to drain glucose from the blood and your blood sugar level gets too low. So when this happens different special cells in the pancreas start to produce glucagon. The glucagon works in opposition to insulin, causing the liver and muscles to convert the stored glycogen back into glucose thus increasing your blood sugar level.
In a healthy person these mini-systems operate quite properly, just like a thermostat, keeping your blood sugar level safely between fairly strict limits. Not too much (hyperglycemia) and not too little (hypoglycemia). They do this by opposing each other. It reminds me of the Goldilocks Principle. Goldilocks didn’t like the bed too soft or too hard, or the porridge too hot or too cold. Goldilocks knew her own mind.
So what have I learned from this? I’ve learned that I understand Le Chatelier’s Principle a bit better if I reword it ever so slightly to start with the word good. Good is a bit weak but I’m a bit pushed for time so it will do for now.
So what is my boarding card example an example of? Does The Inverse Le Chatelier’s principle apply? If a system does not oppose its own proper function is it more likely to be a poor system? I think there's an element of truth to that. If so we have Le Chatelier’s Principles. There are two of them, in opposition to each other, which somehow feels appropriate!
Good systems tend to oppose their own proper function.
Bad systems tend not to oppose their own proper function.
Thanks Hubert.
Predictably Irrational
is the title of an excellent book by Dan Ariely. As usual I'm going to quote from a few pages:
We don't have an internal value meter...rather we focus on the relative advantage of one thing over another
Our first decisions resonate over a long sequence of decisions.
With everything you do you should train yourself to question your repeated behaviour.
Humans are intrinsically afraid of loss.
For market norms to emerge it is sufficient to mention money.
Money, it turns out, is very often the most expensive way to motivate people.
We fall in love with what we already have.
Expectations can influence nearly every aspect of our lives.
The majority of people cheated, and they cheated just a little bit.
What a difference there is in cheating for money versus cheating for something that is a step away from cash!
Thought for the Day
From Small Memory Software by James Noble and Charles Weir.
The fundamental difference between code and data is that programmers care about code whereas users care about data.
Subscribe to:
Posts (Atom)