Technical Explorations Decomposed

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.