Bruce Eckel
Posts: 875
Nickname: beckel
Registered: Jun, 2003
|
|
Re: Programming as Typing
|
Posted: Jul 7, 2006 4:07 PM
|
|
> Isaac, I found "Misstating the Evidence for Agile and
> Iterative Development" and the discussion of it very
> interesting.
The whole thread was fascinating. I especially liked the Feynman quote.
I also found Craig's admission that he had written a lot of the book or the chapter while he was on the road to be interesting. I have run the gauntlet of book publishing over the years, and I know that publishers put a lot of effort into trying to control the author and the schedule, and put great pressure on the author to stick to the schedule (which is usually arbitrary). Only by totally digging my heels in, and basically saying "I'll call you when the book is done, don't bother me until then," was I able to establish my own (mostly) freedom and decide if and when a book is done. Most authors don't know they have this option, because publishers don't want them to think this way. However, I feel that this is the very moment when my books went from "functional" to "pretty good."
The pressure to produce and the relatively small amount you get from the actual advance and book sales make it easy to say that it's not really worth putting all this time in. In my case, if I decide something isn't worth putting the time in, I don't do it. But ordinarily, if an author were to say that a particular chapter would take too long to do right, so it's not worth doing it, the publisher would moan and wail about how critical it is, etc. As Weinberg says, "things are the way they are because they got that way, one logical step at a time." So an author has committed to writing a chapter in a certain period of time and it's basically impossible, so what gives? The quality of the chapter.
I'm not defending Larman. I tend to come down on Issac's side of the fence on this one. For example, when I open a programming book and immediately find an error in a code listing, it taints the whole book for me, and this is why I put so much effort into my code verification system (and even then little errors still slip through!). I understand Ron's argument that the rest of the book could still be valid, but I am then left with the job of figuring out WHICH rest of the book to trust and which other parts of the book succumbed to expedience. I believe that it is the author's job to serve the reader, not to give the reader more work to do -- the reader already has enough work just to understand the main flow of the book, without having to wonder what's right and what might not be.
The real problem is that it takes something like 10x the effort to get a book really, really right. And there are all kinds of pressures -- most notably from the publisher, who has a typical success rate of less than 10% and so easily falls into the attitude of just looking at things statistically, therefore the faster you toss books (they actually call them "titles," as if the stuff inside doesn't really matter) onto the shelves, the quicker you'll get to the successful one. So it's very easy to go awry, and very hard to hold to your own truth. My advice: don't do the project unless you can do it right, holding yourself to your own highest standards.
> To paraphrase "The Princess Bride": Developing software is
> pain. Anyone who says differently is selling something.
I love this. I'm collecting quotes about software development for my next book, which I hope will be very different from anything I or anyone else has done (naturally, I hope that). This one is a definite contender.
That said, I still think that the fundamental shift in thinking that has been successfully put forth by the agile methodologies is the tightening of the feedback loop.
|
|
Previous Topic
