AtelierClockwork

Avoiding Rock Fetches

September 9, 2016

Knowing the Difference Between Freedom and Hidden Objectives

Reading a recent post on Red Queen Coder reminded me a recent, but very useful part of my lexicon of useful programming terms taught to me by Eric Slosser during a particularly stressful moment in a project: the “Rock Fetch.”

Imagine that someone asks you for a rock.

You bring them a rock, they ask for a bigger rock.

You bring a bigger rock, they ask for a rounder rock.

You bring a rounder rock of about the same size, they ask for a slightly smaller, less drab looking rock.

The cycle continues until the person asking is satisfied for reasons you don’t comprehend, you give up in despair at ever finding just the right rock, you get actual requirement on what the rock should be, or you get into a fight about rocks.

Giving me a series of rock fetches is a sure way to tank my motivation, because rather than getting to hit a flow where I’m solving a series of problems and moving along, I have to get the task close to what I think might be correct and then ask for input. This leads to me feeling micromanaged, and often mislead because as the requirements emerge it often means refactoring code to deal with new complications.

The best defense that I’ve found so far is to scrutinize tasks before starting them, and to get solid acceptance criteria before writing any code. Developing the instinct for what makes a task too vague is a challenge, especially as it’s a sliding scale for different phases of projects. At the beginning of a project, every detail needs to be specified somewhere because there aren’t similar examples to pull from. On the other hand, late in a project more vague requirements may be plentiful because of the implied “that functions in a similar way to already implemented sections of the app.”

If there are good reasons for the task to be vague, such as needing to investigate several approaches, then I now try to break that task down into at least two phases. One for actually nailing down what the task will be, then a second for implementation.

I still make the mistake of committing to a “Rock Fetch” task from time to time, but I’m getting better at catching them early, and my sanity and morale have profited quite a bit from it.