Spew Then Organize

[EditHint: Merge with BrainStormFirstCleanLater]

Simple idea in theory, harder to do than you expect in practice.

Basically, write everything you can that's vaguely relevant
Organise the material into a sensible order for a book/article/whatever
Identify and fill the gaps
Proof read and copy edit
Publish

The problem is in the organization stage. It's harder than you think to put it all in a suitable order.

Sounds like a candidate for the IndexCard theme in RobertPirsig's LilaAnInquiryIntoMorals. Relevant excerpt:

http://members.optusnet.com.au/~charles57/Creative/Idea_Recording/lila.htm

The scheme that the main character uses involves spewing ideas as they come onto slips of paper, then working out category schemes for the slips. Pay particular attention to the meta-categories: UNASSIMILATED, PROGRAM, CRIT, TOUGH, and JUNK.

There are a few (fairly informal?) articles out there about how this sort of scheme allows both the left and right brain to get in on the action. In a nutshell: the organized side will beat the creative side nine times out of ten if they're not "separated" and allowed to work at different times. In order to separate them, you do some brainstorming or spewing for a while, reading back over your cards/slips/papers/wikipages/napkins only to look for more ideas. Write more stuff.

Later on, go back to your data units/ideas and begin looking for themes/categories/logical patterns. Otherwise, you'll find (as sometimes I do myself) that brainstorming often gets hijacked by "how the heck should I organize this" type questions and the idea never fully gets off the ground.

---

The problem with this approch, which I both use and suffer from, is that leaving the organising part to the end, as some do with software testing, may leave your final product half backed due to deadlines. I see this often in published works even by renowned authors. It is better to have a smaller more focused end product, even if you do not cover everythig you had hoped, for the same reason that it is better to have a small system which works rather than a large one that does not. If "test early and test often", "code as soon as possible" and "the goal is working code" are the mantras for agile programing, then may I be so bold as to suggest that the organising step can not be put off too long-- it is iterative but short cycles may be best. Also you must ensure that you test your ideas by writing up drafts to share with others who do not share your brain cells-- just like in agile programing. Call it agile writing if you will, but a great many process books would be, in my opinon, far better for this practice.

Marc Grundfest