Thanks... enjoyed reading your first chapter - looking
forward to more!
Roy,
I totally agree. Actually when I wrote my game
programming book I took a Scrum-like approach to it. I
did have to submit the TOC and sample chapters to get
things going but I considered those a 50,000 foot view
of the book with a prototype. After that I took on a
chapter that I liked (didn't start at the beginning) and
would work on it in small pieces (this was all done at
night and weekends). After about a week I figured what I
could achieve so I had my velocity. Then I started to
break down each chapter into it's sections. During the
writing of each chapter things moved around, got
reprioritized and even moved to other chapters as time
went on.
As I was my own Product Owner, Scrum Master, and
Developer I made those choices. Maybe not the best way
to write a book, but I think I did a pretty good job. I
had a clear idea after a month of how long the entire
task was going to be and I hit it so I consider it a
success.
Take it easy, take your time and get it done right. Like
software, I don't think something like this should be
rushed for deadline sake or else you'll just sacrifice
quality or some features you really wanted to put into
it. You're doing a great job from what I see so far and
I (like others) are really looking forward to the end
result!
Just last night I had that same thought! Well, mine was
just related to writing an article for my blog.
I often feel like both code and writing (any creative
task?) would be so much easier if only I could work out
what I was trying to do up front. Unfortunately, it
never seems to be possible - the requirements aren't
something that seem to exist beforehand - they get
generated or modified as development or writing
progresses. Or is it just a lack of a disciplined
approach ?
That's pretty much how I felt when writing Professional
Team Foundation Server. Good Luck! Shoot me an email if
you need a tech editor.
I loved the fact you talked about integration tests.
It's a confusing topic that people tends to mix with
unit tests.
Looking forward to reading your book.
I would agree with the comparison between writing and
software development. In classic books about good
writing like William Zinsser's "On Writing Well" the
point is made that good writing means continually
modifying and editing pages, paragraphs, and sentences
over and over again till you get it right. With each
iteration of changes you try to simply your language and
remove excess words--which results in powerful,
easy-to-understand, quality writing.
Basically it's just refactoring.
The other interesting thing is that people like Zinsser
constantly bemoan all the example of terrible writing
that are ubiquitous today: lots of business blather that
says nothing. The classic example is the word "utilize".
It's longer and sounds more sophisticaed than "use" but
adds ZERO meaning in most cases. Obviously it's the same
with code.
To me "software development as writing" is a better
paradigm than the more traditional ones like "software
development as construction" or "software development as
gardening".
You are right on the money 100%. All we need now is to
find a publisher that agrees and see if we can change
the process of writing books :)
(btw mine is out soon and it was much harder than what I
initially thought... keep the faith!)
Book writing obviously has been around long before
programming. It seems odd you would make a reverse
comparison....
Programming is like writing a book.
I didn't find the process to be all that similar (my
book:
http://www.amazon.com/exec/obidos/asin/0321294475/coasterbuzz-20).
Working with A-W was more of a "big bang" delivery
process than one of iterations. The editorial review
process was a little like a code review though.
Same here for the book I wrote in '96 with Jeff. Much
time was spent on the TOC that we wanted to change up
but it was too late. It is very much a waterfall process
in terms of working with publishers, but an iterative
process when writing. I learned my lesson.
I'm now focusing more on ebooks, with my first one on
volunteer leadership coming out soon. I must have
changed the outline about 5 times before I got the
reader experience right.
Jeff, James, I guess that the experience can vary
depending on the publisher.
See my own experience:
http://linqinaction.net/blogs/main/archive/2007/03/13/my-writing-experience.aspx
I've found that too. You start off with broad
parameters, then the development/drafting is a process
of refinement and refactoring.
The main difference between them (to my mind) is whether
a book release 'works' or not - more of a subjective
test metric that an objective one!
Oh, I most definitely agree re starting with a good
table of contents. I was primary author of a couple of
development books for NewRiders Press back in the early
90's ("Inside FoxPro for DOS" and "Inside FoxPro for
Windows" -- I'm dating myself here). The publisher
offered me the project based on what they termed the
"lucidity" of my postings to a MSFT beta forum they were
lurking on. But I initially turned it down because the
Table of Contents / outline sucked. They said in effect,
"well fine ... let's see YOUR outline" ... and the rest
is history.
If you can't construct a book outline / TOC you probably
can't write decent software. You have to know where
you're going ... as you point out you'll refine it as
you go but you can't just plow in and write what pops
into your head ... you'll end up with a rambling, and
possibly incoherent, book.
It would be interesting to find out how to do TDW
(Test-Driven Writing) ;-)
Fabrice,
I totally agree - Jeff Schneider and I had Que as a
publisher, who in '96 and '97 were going through some
internal transitions that impacted the success of the
book.
The lesson: pick your publisher carefully!
I've heard great things about Manning, even in the early
days. Duane Fields, Mark Kolb, and I compared notes on
the two publishers and they were worlds apart. I would
consider writing another book, but it would have to be
the right publisher first.
It was comforting to see that others share the same
problems :)
I just spent a couple of months "remodeling" chapter 1
and "refactoting" chapter 2 before (finally) going back
to writing new chapters