ndanger.organism

One of the parts I liked about The Myths of Innovation (full review) was the simple description of brainstorming:

1. Facts
2. Ideas
3. Solutions

I’ve previously had some issues with TDD, and viewed in Scott’s three steps I realize it’s simply: TDD skips the idea phase.

The facts are the problem you’re trying to solve, and the solution is the end product. I guess the ideas are supposed to be the the tests & code, but that just doesn’t work for me. Maybe I need nimbler fingers but I suspect that the real problem is that code is too limiting. By nature, programming distills an abstract idea into instructions so simple that even the world’s fastest idiot–a computer–can understand them. This clear, orderly expression of ideas is too limiting for the free association that generates new ideas.

Or maybe it means that I’m not yet fluent in my language (Python) or the underlying language of programming (architectural decisions, algorithm complexity, etc.)? Perhaps being a master programming is a fluency such that it’s faster to sketch in Emacs than on paper; familiarity has certainly cut down on my need for crutches. Master level fluency also explains both the talented programmer’s obsessive devotion to their chosen language/environment and love of learning new languages. The first aids expression, like an artists well-lit studio or a gamer’s abbreviations and slang. The second expands the range of expression, like an artist trying a new medium or a gamer going outside.

But if expressing ideas in TDD requires fluency, then its purest “test&code” implementation is only useful for master level programmers. Is this an example of how agile is only for elites? (more “agile only works for elites” links welcome, I know there are more but couldn’t find them)