I had every intention of sending Modern Perl: the book to the printer last week, but a funny thing happened along the way when I proofread the index.
Perhaps I've been writing software too long (and in the technology world before that); sometimes I look at problems as if they were software problems. I've written several books before. I've edited several books too. I understand publishing (which is a good thing to have if you're a partner at a publishing company).
I knew that a good index makes a good book great just as a poor index drags down a good book. I planned from the start to sprinkle index tags liberally through the manuscript as I wrote it. What better time to indicate which topics are most important than when I mention them?
That worked—at least better than trying to add the relevant index tags after the fact.
Then I built the index for the first time and realized that consistency of index is very, very important. By the time I'd proofread the index once, I knew far more about what I wanted to index (and, more important, how) than I knew when I finished writing the manuscript.
The second 80% of the work went more quickly than the first 80%.
Yet because I've spent so long writing software and exploring project management, I couldn't help but remind myself of that always-important project management mantra: you know the most about what you need only at the point when you most need it.
That's one reason we at Onyx Neon have invested so heavily in making it possible to produce a new book from a draft manuscript within a minute or two (including the index), and that's one reason I care so much about iterative development. I like what I see in Rakudo, with it's feedback-driven prioritization for Rakudo Star development and projects such as Dist::Zilla which, even though it moves quickly, has evolved quickly to a very usable, very powerful system.
The more you know, the better decisions you make. It works for books as well as it works for software development.
(For a longer treatment of the idea of "the last responsible moment", see my colleague's A Tale of Two Vacations.)
