Monthly Archives: December 2003

Context-Driven Driving

Posted on by
7

I know how to drive. I have a lot of experience as a driver. I’ve been a driver for 17 years or so. For me, driving has become easy. Now, that doesn’t necessarily mean very much. I have no experiences with stunt driving, NASCAR, or big rigs. Still, until recently I thought I had “ordinary driving” down as pat as it gets.

Then I visited Bangalore, India. I didn’t drive in Bangalore, but as a passenger on fourteen taxi trips, I got to observe driving techniques. What I saw there changed my notion of what is safe driving, because of the cognitive dissonance between my “proven safe” driving rules and the fact that near constant violation of those rules by everyone on the streets seems to lead to far fewer accidents than I would expect.

Here’s how it goes in Bangalore:

  • Buses, trucks, smaller trucks, small cars, teeny-tiny cars, motorized three-wheel rickshaws, motorcycles, mopeds, bicycles, people, cows (in singles and herd form), and dogs, all share the same road. Probably two thirds of the vehicles on the road have three wheels or less.
  • Vehicles drift from lane to lane, mostly without using turn signals. Vehicles often share lanes and pass each other within the lanes.
  • In the twelve or thirteen mile stretch between my hotel and work, I counted three stoplights. Mind you, this is in the middle of a city of six million people, not a country drive.
  • Road signs, including stop signs, seemed to be ignored.
  • Clearance between vehicles is a fraction of the minimums we observe in America. Bangalore is a city of tailgaters.
  • Few motorcyclists had helmets, and many had people, including women holding babies, perched side-saddle on the back.

The visual experience of being in the taxi reminded me of dogfight scenes in Star Wars. I expected to hear the driver say “Don’t tell me the odds” as he plunged into an asteroid field. Halfway through the week it occurred to me that Disney could create an exciting and educational ride called “The Bangalore Experience”, or maybe an IMAX movie out of this.

See this video for an example of what it’s like.

Every morning of my stay I took a 45 minute cab ride from my hotel (the wonderful ITC Windsor Sheraton Hotel and Towers) to the place I was to teach. The first trip was hair-raising. I gripped the handhold and placed my briefcase in “brace” position. By the second day, I noticed that we hadn’t yet been in an accident. By the third day, I began to look carefully for evidence of accidents of any kind. I found nothing: no vehicle debris on the road, almost no one driving with a dented bumper, only one emergency vehicle seen for my fourteen rush hour trips.

The stark contradiction between empirical evidence and my predictions led me to look closely for the difference in context between American driving and Indian. Here are some of my observations:

  • Drivers are alert: If you expect people to cut you off at any second, you drive with one foot on the brake and a sharp eye. My driver reminded me of my son playing a cideo game. Eyes riveted on the road.
  • Honk for safety: Horns are used very frequently. A blast every few seconds. Many trucks had hand-painted signs on there rear bumpers saying “please honk”. In America, honking the horn is almost always an expression of irritation or outright rage. Horns are honked from anger and hearing them evokes anger. In Bangalore, honking is a matter of politeness. I distinguished three kinds of honking: bip, beep and beeeep. Bip is a quick honk that means “hi” or “ahem” and is used to alert another driver to our presence. “Beep” is a longer honk that seems to mean “excuse me, I would like to move through here.” And “beeeep” means “Please stop blocking me. Okay, thank you for moving.”
  • Drivers seem to be calm in the midst of traffic. I didn’t see anyone obviously angry, anyway. I think Americans in the same situation would get pretty frustrated.
  • Slow speed: According to my GPS, our typical speed was 25 mph, and we never exceeded 40 mph. The lower speeds mean shorter stopping distances and generally more time to react.
  • Small vehicles: They just have more room to maneuver than we do on a typical American street, because we drive mostly full-size cars.

Context-driven methodology says that there are no best practices, only good practices in context. In the context of Bangalore, a different set of driving rules seem to be working. Now, I do know about statistics, and my observations were not quantitative, so maybe it is actually the case that there are a lot more accidents per capita than here in the States. Nevertheless, I would have predicted carnage and gridlock, and that obviously was not their situation.

Technical Explorations Decomposed

Posted on by
2

I’ve been thinking about the general nature of technical explorations. Let me take a hack at describing them.

A technical exploration is a self-directed, cyclic process of problem identification and problem solving intended to fulfill some technical purpose. Technical exploration is influenced by resources, constraints, and stakeholders within the project environment. Technical exploration is a broad category that encompasses many kinds of projects and processes, large and small, such as:

  • Bug investigation
  • Exploratory testing
  • Porting a test suite
  • Designing and implementing a test suite
  • Designing and implementing a test process
  • Creating a new tool

By definition, a technical exploration involves something technical and something unknown. By implication, a technical investigation involves a problem that has no obvious or deterministic solution. Finding the square root of 2 to 33 significant digits is a technical problem, and does involve an unknown, but there is an obvious and deterministic procedure for solving that problem. Not much of an exploration, there, unless you want to explore the process of deriving a method to take square roots.

We call something a technical exploration in a project when the situation is such that there are many possible solutions, and the best solution is not immediately discernible. It’s a situation that is complex enough to require the assignment of an engineer to ponder the problem and organize resources as necessary to effect a solution.

Technical explorations are fundamental to the development and testing of technology, yet they are often seen as just an art or perhaps a talent– not something that can be described or taught in a structured way. Certainly there is substantial element of art and talent in exploration, but I found that in my observations of exploratory practices there is also quite a bit of describable and teachable behavior.

Successful technical explorations share these attributes:

  • Self-directed, as opposed to dictated from outside.
  • Cyclic, not linear.
  • Mission and problem-driven, as opposed to procedure-driven.
  • Learning is part of the mission.
  • We accept that the process is not fully predictable.
  • We accept the risk that some of our efforts may not pay off.

Technical explorations typically also involve:

  • Multiple stakeholders to satisfy.
  • Coordination with stakeholders and helpers who are only intermittently available.
  • Formation and dissolution of ad hoc teams.
  • Research into processes or technologies, whether new or legacy.
  • Requirements that are ambiguous, unknown, evolving or conflicting.
  • Work products that are difficult or impossible to anticipate at the start of the process.

Excellent technical explorers have these skills:

  • Ability to think playfully about serious matters.
  • Ability to make observations and assimilate them to a mental model of the situation.
  • Ability to change a mental model to accommodate new information.
  • Ability to model one situation is many different and possibly incommensurable ways.
  • Ability to relate any idea to any other idea.
  • Identifying and consulting with people who might have important information or useful contributions.
  • Identifying, acquiring, and studying documents.
  • Identifying, analyzing, articulating, and negotiating the mission and sub-goals.
  • Identifying, analyzing, and negotiating conditions in the environment that affect the exploration.
  • Identifying, analyzing, articulating, and applying heuristics that assist exploration.
  • Identifying, analyzing, and articulating what you need to know.
  • Focusing exploration by working backwards from goals.
  • Focusing exploration by identifying and pursuing tasks most likely to achieve goals.
  • Focusing exploration by identifying, and eliminating tasks that don’t serve the goals.
  • Identifying exploratory dead-ends and backtracking.
  • Forming, testing, and modifying conjectures and recommendations.
  • Reporting and qualifying conjectures and recommendations.
  • Forming and reporting assessments of technical and project risks.
  • Reporting and projecting progress of a cyclic investigation.
  • Creating useful and maintainable documentation.
  • Arranging and facilitating meetings.
  • Soliciting reviews of work, and processing feedback.
  • Ability to feel fear (of failure, of the unknown) without being incapacitated by it.
  • Ability to see value in a failure.
  • Ability to see failure in success.
  • Ability to maintain loose ends and accept distractions.
  • Ability to leave an exploration and return to it without losing state.
  • Ability to branch an investigation into sub-investigations.
  • Cultivating information resources and tools that facilitate exploration.

Testing Heuristic: Rumble Strip

Posted on by
3

A rumble strip is a strip of corrugated pavement running alongside highways. If you go to sleep and and drift off the road, the wheels of your car hit the rumble strips and that makes the car vibrate with a loud BUR-R-R-R-R-R. A rumble strip doesn’t damage your car, but it’s an alarming event all the same, because it means that you’re about to have a major accident if you don’t do something to get back on the road.

Programs are like cars driven by notes left by an absent programmer. For testers, hearing the rumble strip means a good bug is literally around the corner.

The rumble strip heuristic in testing says that when you’re testing and you see the product do strange things (especially when it wasn’t doing those strange things just before) that could indicate a big disaster is about to happen. By “strange” I mean behaviors that you are confident the programmer did not intend. For instance, I was testing an input field once and at 23,829 characters all the text turned white. This is a strange bug, but mainly it served as a rumble strip under the tires of the absent programmer. I knew the program was leaving the highway, so I kept pushing with my tests until I got it to crash.