This series is about design process and organizing our thoughts for effective development. The main goal is to establish a healthy mental model and intuition for effective design process. We’ve previously established core ideas about design process and now well dig into concrete techniques. And yes, finally explain the ducks.

What’s Your Duck

There’s an old programming joke that if you’re stuck on a problem, you should explain it to a rubber duck and the duck will help you solve your problem.

Rubber ducking is a bit silly, but actually a very useful technique. The reason is that it encourages us to be wrong rather than vague. Explaining our problem to the duck pushes us to organize our thoughts enough to explain. Organizing our thoughts exposes holes in our mental model and thus gets us unstuck.

This process doesn’t have to be done with a rubber duck. It can be a coworker, a design document, a drawing, or anything that causes you to organize and communicate your thoughts. Thus the question: “What’s your duck?”

Duck Docs

I use a process that I call duck docing where I pair program with a text document. It started because I was working as a solo developer and felt the gap left by pair programming.

The structure is fairly loose, but the general structure is

Motivation: I always start by explaining the motivation of my current work in plain language

Requirements and Constraints: As described in Self-Similar Process, next I enumerate known qualities of a solution. This forms a baseline definition of done. This may also be provided by an up-stream requirements process.

Knowns & Unknowns: With core requirements in place I start exploring the problem by listing

  • Knowns: what I already know about the problem and think will be helpful
  • Unknowns: anything I think I need to know about the problem but don’t know. These often come in the form of questions.

Knowns and unknowns lead into questions and sub-problems, which lead to hypotheses, experiments to prove or disprove my hypotheses, and finally knowledge to fold back into the overarching goal.

The process has evolved a flexible structure that doesn’t inhibit my flow of thought, but promotes easy reference to later extract key information. I’ve even built tools to leverage this structure since it effectively turns notes into data.

The quality of your questions determine the quality of your answers

Asking good questions that lead us to the heart of a problem is a valuable skill in itself. The next post will talk about questions and ducks techniques for specific software life cycle phases. You can also check out an example duck.