42. Snorkeling and Scuba Diving

Analysis activities continue through the life of the project: top-down, bottom-up, and middle-every-which-way.¹

¹ Thanks to Dines Hansen for inspiring the pattern statement.

A snorkeler swimming across the surface of the water sees fish swimming in the shallows and the shadows of creatures in the depths. A scuba diver goes farther below the surface of the water; he makes deeper dives and investigates the shadows to discover details of the fish, wrecks, and coral in a specific area. Given the same amount of time, snorkelers cover more breadth; scuba divers, more depth. Successful project teams make effective use of time by combining the skills of snorkeling and scuba diving throughout the project and by making reasoned choices about which approach to take, when.

Snorkeling is a fine technique that project teams can use to discover how much area needs investigation in order to understand the problem and meet the goal. Typically, at the start of a project or sub-project, snorkeling identifies the scope of the investigation, the goals, the stakeholders, the boundaries of the investigation, what is already known, and where some scuba diving needs to be done.

The diver makes a deep scuba dive when he suspects there is something interesting to see, something new, or some deeper detail. A deep dive often yields discoveries that change assumptions made while snorkeling. Suppose we discover a species of marine life we didn’t expect to find in these waters; then we’ll need to make a wider investigation to find the species’ breeding ground.

An indication of this pattern is when a team takes a wide (snorkel) view in parallel with—not instead of—doing selected, detailed (scuba) work. What’s key is the ability to apply wide and deep investigatory skills throughout the project. The width of the investigation identifies people, organizations, hardware, and software systems that might have some effect on the project. Increasing knowledge about the width identifies the areas of highest risk and greatest benefit, areas that would provide profit from a deeper investigation.

Project teams that snorkel and scuba dive are not daunted by a wide scope. Team members know they do not need to investigate the entire scope to the same depth. For example, if they decide to buy a solution for part of the scope, then the depth of that investigation is only as much as is needed to fit the work situation to the capabilities of the solution. When they intend to build their own solution, they make judgments on what depth of investigation is necessary for the proposed changes. They also know that some of the deeper investigation can be deferred to a more convenient time. Project teams with a wide scope are better able to respond to changes because they can see the ramifications of the change. They know what they know and what they don’t know, what they need to explore and what they can leave alone. They can plan how to use resources to their best advantage.

Projects that snorkel and scuba dive are highly likely to use prototypes and simulations in conjunction with context modeling. They are also likely to incrementally deliver the most beneficial functionality early in the project. Also, they are able to coherently explain the scope and goals of the project in one page.

The opposite of this pattern is when a team is either addicted to detail (“We only do scuba diving—none of that sissy snorkeling”) or scared of detail (“We’re snorkelers—in other words, afraid of sea monsters”). You will also spot the opposite when people talk about “high level” and “detail” as if these are separate things that don’t need to have any traceable relationship.

Good developers do not limit themselves: They can snorkel and scuba dive. They choose the technique depending on what they need to see. When reconnoitering, a shallow dive will suffice, but inspecting necessitates a deeper dive.

Sometimes, just dipping your toe in the water is enough to tell you not to plunge in.