observing

Back to quotes table-of-contents

From The Psychology of Computer Programming

If egoless programming is used, everyone in the group will have the opportunity to examine the work of everyone else at some time, thereby tending to prevent the establishment of strong hierarchy.

From Toyota Production System

Sometimes I would spend all day watching the grandmother next door weaving. I came to understand the way the weaving machine worked. [Toyoda Sakichi]

Stand on the production floor all day and watch - you will eventually discover what has to be done. I cannot emphasize this point too much.

From The Way of the Leader

Listen carefully. Observe closely.

From Zen and the Art of Motorcycle Maintenance

By far the greatest part of his [the mechanic's] work is careful observation and precise thinking.

From Non Violent Communcation

Observing without evaluating is the highest form of human intelligence.

From Wit and Wisdom from Poor Richard's Almanac

Observe all men; thyself most.

From The Mind of War

He observed very carefully.

From Quality Software Management. Vol 2. First-Order Measurement

In the end, it's not the observation that counts, it's the response to the observation. That's why Zen masters teach patience in response.

What power corrupts most thoroughly is the ability to make meaning of observations.

No other observational skill may be more important to software engineering than precision listening.

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].

A fact becomes a feeling as soon as you observe it.

From An Introduction to General Systems Thinking

We drive more slowly at night to give us more time to observe potentially dangerous situations.

From Zen Mind, Beginner's Mind

The true purpose is to see things as they are, to observe things as they are, and to let everything go as it goes.

From The Book of Five Rings

You should observe reflectively, with overall awareness of the large picture a well as precise attention to small details.

From Pragmatic Thinking and Learning

Much of perception is based on prediction.

From General Principles of Systems Design

Complexity is a relationship between system and observer.

what should all tests passing look like?

I was fixing a fault in cyber-dojo the other day and I happened to be looking at the starting test code for C++. I'd written it using an array of function pointers. At the end of a practice the array might look like this (in main I simply iterate through the array and call each of the functions):

typedef void test();

static test * tests[ ] =
{
    a_recently_used_list_is_initially_empty,
    the_most_recently_added_item_is_always_first,
    items_can_be_looked_up_by_index_which_counts_from_zero,
    items_in_the_list_are_unique,
};

I imagined it written like this instead:

int main()
{
    a_recently_used_list_is_initially_empty();
    the_most_recently_added_item_is_always_first();
    items_can_be_looked_up_by_index_which_counts_from_zero();
    items_in_the_list_are_unique();
}

I wondered why I was putting the function pointers into an array at all. The most obvious thing I lose by not using an array is that I can no longer print out the number of tests that have passed. I thought about that a bit. I started to wonder what benefits I actually get by being told how many tests had run. It's a 100% quantity and 0% quality measurement.

The most obvious benefit I can think of is that, after writing a new test, I can verify it has run by seeing the number of tests increase by one. The problem is I don't think that's a benefit at all. I think that interaction could easily encourage me to not start with a failing test.

If all tests passing produces any output I will look at the output and start to rely on it. That doesn't feel right for a supposedly automated test.

If each passing test introduces any new output, even if it's just a single dot, then I'm in danger of falling into a composition trap. Those dots don't make a difference individually, but sooner or later they will collectively.

If the code I'm testing doesn't produce any output when it runs (which is very likely for unit-tests) then is it right for my tests to introduce any output?

If I want to time how long the tests take to run shouldn't that be part of the script that runs the tests?

I think there is something to be said for all tests passing producing no output at all. None. Red means a test failed and the output should be as helpful as possible in identifiying the failure. No output means green. Green means no output.

Thoughts?