Stream of Consciousness Driven Development

# Stream of Consciousness Driven Development Source: [https://buttondown.com/hillelwayne/archive/stream-of-consciousness-driven-development](https://buttondown.com/hillelwayne/archive/stream-of-consciousness-driven-development) This is something I just tried out last week but it seems to have enough potential to be worth showing unpolished\. I was pairing with a client on writing a spec\. I saw a problem with the spec, a convoluted way of fixing the spec\. Instead of trying to verbally explain it, I started by creating a new markdown file: Then I started typing\. First the problem summary, then a detailed description, then the solution and why it worked\. When my partner asked questions, I incorporated his question and our discussion of it into the flow\. If we hit a dead end with the solution, we marked it out as a dead end\. Eventually the file looked something like this: ``` Current state of spec Problems caused by this Elaboration of problems What we tried that didn't work Proposed Solution Theory behind proposed solution How the solution works Expected changes Other problems this helps solve Problems this does *not* help with ``` Only once this was done, my partner fully understood the chain of thought,*and*we agreed it represented the right approach, did we start making changes to the spec\. ### How is this better than just making the change? The change was*conceptually*complex\. A rough analogy: imagine pairing with a beginner who wrote an insertion sort, and you want to replace it with quicksort\. You need to explain why the insertion sort is too slow, why the quicksort isn't slow, and how quicksort actually correctly sorts a list\. This could involve tangents into computational complexity, big\-o notation, recursion, etc\. These are all concepts you have internalized, so the change is simple to you, but the solution uses concepts the beginner does not know\. So it's conceptually complex to them\. I wasn't pairing with a beginning programmer or even a beginning specifier\. This was a client who could confidently write complex specs on their own\. But they don't work on specifications full time like I do\. Any time there's a relative gap in experience in a pair, there's solutions that are conceptually simple to one person and complex to the other\. I've noticed too often that when one person doesn't fully understand the concepts behind a change, they just go "you're the expert, I trust you\." That eventually leads to a totally unmaintainable spec\. Hence, writing it all out\. As I said before, I've only tried this once \(though I've successfully used a similar idea when teaching workshops\)\. It worked pretty well, though\! Just be prepared for a lot of typing\.