Daydream Driven Development


An infinite number of software development methodologies exist to address an infinite number of hindrances. For my own side projects, I have defined my own methodology: Daydream Driven Development.

The “Hindrances”

  • During regular business hours, my brain cycles are primarily dedicated to my fantastic employer, Faithlife .
  • In the evening, I like to spend time with my wonderful wife, Elvira.
  • On weekends, I spend the majority of my time away from any computer.

These are good things! However, they generally result in a greatly reduced volume of output in regards to personal coding projects.

On most weeks, I set aside one evening a week to spend on coding side projects, but even during that time, I frequently run into the following:

  • I spend time looking at how others have solved similar problems or built similar projects.
  • I spend time reading about how others have dismissed my problems or projects as not worth the time to solve or to build.
  • I spend time reading about how my ideas are not at all technically feasible.
  • I spend time reading completely unrelated topics from Hacker News.

These aren’t bad by themselves, and can reasonably be considered as their own form of “learning”, but it is not nearly as enjoyable as digging in and learning from my own mistakes.

The Method

All my side projects start with a Daydream Document which describes the following:

  1. The hook: what prompted me to think of this project?

    • A technology that I want to explore?
    • A pain point that I want to address?
    • A domain name that was available on NameCheap? (and probably on sale!)
  2. The dream: without regard for hindrances, what would a shipped version of this project look like?

    • It is critical at the Daydream Stage that I ignore all hindrances. It is all too easy to get sucked into thinking of reasons not to do the project. But the purpose of this stage is to take the chance to dream of reasons why this project deserves more attention than any of the others.
    • Without a well-defined dream, the laws of inertia state that a side project will never get worked on, let alone shipped.
  3. The unknown unknowns: what questions would move this project forward?

    • At the Daydream Stage, it is important to capture the questions but not spend any time answering them.
    • It is entirely possible that the answer to one of these questions will guarantee that the project will not move forward, but by deferring the answering of questions until after the asking, I get to enjoy the Daydream a little while longer and benefit from the exercise.

One advantage of explicitly separating the Daydream Stage from any Implementation Stage is that Daydreaming can happen anywhere: in the elevator, in the car, on the beach. Those thoughts can be appended to the Daydream Document whenever convenient.

Executed well, a Daydream Document can provide a sense of progress and completion, even if no implementation is inspired by it. The Daydream Document can be an end unto itself.

Flow Sizzle

Elegance and Shipping