Inkwell: Authors and Artists

    
The Inkwell is pleased to welcome longtime Well member, Scott Rosenberg.

Scott Rosenberg is a writer and editor who cofounded Salon in 1995 and is
the author of "Dreaming in Code" (Crown, 2007). He served as Salon's first
technology editor, became managing editor in 1999 and served in that
position through 2004. In 2005 he took a leave to write "Dreaming in Code"
and returned to the company in 2006 as vice president for new projects.

Before Salon he worked as a critic for the San Francisco Examiner for a
decade, first as its lead theater critic (his work won the George Jean
Nathan Award in 1989), then lead movie critic, and finally digital culture
columnist.

Before joining the Examiner he wrote theater, movie and book reviews for the
Boston Phoenix.

Christian Crumlish, who will lead the discussion with Scott, has been
analyzing application interfaces since 1987, writing about the social
implications of technology since 1992, and developing interactive
experiences since 1994. He is the curator of the Yahoo! pattern library and
he currently serves on the board of directors of the Information
Architecture Institute. He has consulted with startups and Fortune 500
companies, including FedEx, Kodak, Visa, Sprint, Charles Schwab, Safeway,
Sun, SanDisk, BEA, HTC, Aramark, MediaMelon, Syklist, and GoFish.

He is the author of, most recently, The Power of Many: How the Living Web is
Transforming Politics, Business, and Everday Life. Christian earned his
bachelor of arts in philosophy from Princeton University in 1986. He is the
host of the Blog conference on The Well, contributes to You're It! a blog on
tagging, and presents other slivers of his identity in blog form at X-
POLLEN. He lives in Oakland, California with his fiancée, Briggs, and his
cat, Fraidy.

What's up, you two?
  

    
Hey, Scott! I know this book was several years in the making. (I
remember when you announced on your Salon blog that you were taking a
sort of sabbatical to research a book.) I'd love to start off with the
genesis of the project:

What was the original inspiration for the book?

How did you pitch it to your agent?

How did the book's concept evolve over time (if it did)?

At what point in the project did the title occur to you?

At what point in the writing did you feel like you knew what the
lesson, or moral, or meaning of the book was turning out to be?
  

    
Five questions in one! I'll try to work my way through, one post per 
question. 
 
First, though, let me just kvell a bit over my own trajectory here. I got 
my first real online experience on the Well 15, 16, 17 (?) years ago, 
reading lines of type slowly scrolling at 300 baud. So being here talking 
with folks about my first book -- it's good. Thanks to inkwell and to 
everyone at the Well for inviting me to do this.
 
DREAMING IN CODE started, as I describe in the introduction, with my 
experience as one of the managers of Salon's initially ill-fated redesign 
project that launched in May 2000. It was the height of the bubble (in 
retrospect, it was clear that the bust was just beginning as we were 
struggling to deploy our project, in fact). We made the mistake of tying a 
total overhaul of Salon's design to a total revamp of its content 
management software, and then tying all that to several major business 
initiatives that had calendar deadlines. And the whole thing turned out to 
be a disaster on launch (though, after several weeks' chaos, we began to 
clear the rubble and ended up with a perfectly good content management 
system that we're still using today!). 

I'd become a father of twin boys six months before, so my memories of that 
era are filtered through a haze of vague euphoria cut with massive amounts 
of sleep deprivation. But I definitely felt stunned and bruised by my 
software-disaster initation: How could this happen? I figured I was just a 
writer, ignorant of the actual practice of software development and 
surrounded by people who were talented but green; so I did what I've 
always done in such situations -- I hit the books. I went and read 
Frederick Brooks' THE MYTHICAL MAN-MONTH and had the little epiphany that 
the kind of endless-delays-leading-to-train-wreck-deployment experience 
I'd been through was what people in the software field had been 
experiencing at least since Brooks' day, at IBM in the '60s. Even though 
there were plenty of mistakes we'd made out of our own ignorance and 
inexperience, knowledgeable veterans hadn't licked the problem, either. 

I'd toyed for years with the idea of some kind of book about programming 
and language -- I had a whole folder of code snippets in different 
languages, I'd been imagining something very artsy and fun but 
theoretical. But this problem struck me as a better book idea.

I didn't want to write a how-to book (plenty of good ones out there 
already), and I'd always aimed my technology writing at the overlap 
between the circles of interested outsiders and generalist insiders. Even 
though most of my journalism has been criticism and columns, for a book I 
felt that the best approach would be a good old-fashioned narrative spine, 
cut with more essay-like background material. 

My initial thought was, I'd go find a half dozen projects and tell their 
stories and weave the narratives together creatively and use all that 
material as a way to look at why software is so hard, and what avenues 
people are pursuing today to make things easier. 

Around that time -- this would be fall 2002 -- Mitch Kapor announced the 
Chandler project: open-source, cross-platform, peer-to-peer, free-form 
personal information management. I'd long been interested in the whole PIM 
field, I'd written several Salon columns about it. I'd never met Kapor but 
I knew and admired his work. I thought, perfect, this will be my first 
project. Kapor was cautious at first but basically open. 

Once I started following the work on Chandler, in early 2003, I realized 
how insane my six-projects-in-one concept was: Too Much Information. One 
project was already pushing my limits. Multiple projects would be too much 
even for me to get my head around, let alone ask a reader to follow. And 
Chandler seemed like it had it all: an interesting cast of characters 
(with names at least some potential readers would have heard of, like 
Kapor, Andy Hertzfeld and Lou Montulli), an interesting problem to solve, 
an ambitious set of goals. I felt confident I could use it to get at most 
of what I wanted to get at. I was up front with Kapor and the rest of the 
people at the Open Source Applications Foundation about the change, and I 
think by then they'd seen enough of me to feel they could trust me to 
tell their story fairly. 

This was spring 2003, when the Iraq invasion was unfolding, so the joke
became that I was an "embedded journalist" in the software team. I'm
afraid that in retrospect it's a bitter joke, because both the Iraq fiasco
and the Chandler project dragged on years longer than anyone expected or
planned. But fortunately the parallel does finally collapse, since, as of
today, unlike the U.S. adventure in Iraq, Chandler at least still holds
the potential for a positive outcome.

OK, that's a full essay just to answer the first question. I'll tackle  
the others more concisely in a next post...
  

    
go long if you like! 
  

    
That's a dangerous invitation :-) 

As far as pitching it to my agent: this was 2003, in the trough between 
the bust of the old Web bubble and the rise of the new Google-fueled Web 
economy. So at that time the New York media world, of which book 
publishing is a subcategory, was pretty down on technology and technology 
books. I had to make a case that seemed transparently obvious to me -- 
that software runs our world and its problems are our problems. The good 
news is, my agent was (and is) both thoughtful and patient, and I worked 
for probably six months on the proposal -- first by myself and then with 
him. We didn't take it to publishers until around March 2004. 

The evolution of the concept I think I covered above. Once we had the 
proposal I really stuck close to it: I would tell a tale (about Chandler) 
to try to answer a question (why is it so hard to make software well?).

I conceived of the title very early on, even before I connected with the 
Chandler project. It just seemed a great, pregnant phrase; it contains 
multiple meanings -- a dream communicated or expressed via code; the 
actual experience some programmers have of seeing computer code in their 
dreams; "dreaming" as thinking bold new thoughts and "dreaming" as the 
opposite of acting in a concrete way. 

The subtitle, on the other hand, took forever to nail down. I originally 
wanted something simple and declarative, like "Dreaming in Code: Why 
Software is Hard." But wiser heads -- mostly, that of my wonderfully 
talented editor, Rachel Klayman -- prevailed on me to use the subtitle to 
communicate to people that the book indeed tells a story, of people 
struggling with technology. One day I was idly scrolling through my RSS 
feeds and I noticed the title of Julie Powell's book, JULIE AND JULIA -- 
she was a blogger in the old Salon blogs program who'd cooked her way 
through Julia Child's cookbook, and turned that saga into a book. Powell's 
subtitle was "365 Days, 524 Recipes, 1 Tiny Apartment Kitchen," and that 
inspired me -- so thank you, Julie! (Only now I notice they've actually 
changed her subtitle for the paperback edition, to "My Year of Cooking 
Dangerously.") It just took a little time to fine tune the details to end 
up with "Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for 
Transcendent Software." I document and explain those numbers in the book's 
endnotes, which are all online over at 
http://www.dreamingincode.com/endnotes/

To the last question, at what point I felt like I knew the "lesson, moral 
or meaning" of the book: For me, that's a more challenging question than 
it seems. 

I've spent most of my writing career as a critic and a columnist. I'm used 
to trying to derive lessons and meanings in 1000 words, and I think at 
times I've been pretty good at that. But for this -- my first book after 
two decades of full-time professional writing! -- I really wanted to do 
something different. The nonfiction narratives (and indeed the fictional 
narratives) that I admire most deliver their stories without any 
pronounced underscoring of "lesson, moral or meaning." The story stands as 
what it is and the readers come to their own conclusions. Of course the 
story's shape will point people more in one direction than another; but 
there's always room for multiple interpretations. 

That's what I hoped to achieve with DREAMING IN CODE: I wanted the story 
to illuminate a certain abstruse realm of human creativity, and I intended 
to leave room for different readers to draw different conclusions. Of 
course there are some broad and relatively obvious points: it's likely, 
for instance, that most readers of my book will conclude that one should 
be careful about starting a software project with too broad and vague a 
set of ambitions. But I'm finding, happily, that readers are identifying 
all sorts of other, less obvious, and sometimes conflicting, lessons in my 
text. 

That makes me smile; it tells me I might have managed to write 
something more complex than a 1000-word essay or column, something that 
might be worth a reader's twenty bucks. Of course it could also mean I 
just wasn't clear. But I'm optimistic that this is the valuable and 
interesting species of ambiguity, not the kind that just leaves you 
scratching your head. 
  

    
That's a great answer. I think that is one of the rewards of
longer-form writing, that the work makes its own connections in your
readers' minds. You do not have to consciously explicitly place each
nugget of goodness there for them to find.

I asked about when you discovered the meaning not so much to reduce
things to a moral but out of sense of curiosity about how the story
hung together for you in the writing. By analogy to the only nonfiction
book I've written (not counting how-to/manual type stuff), I completed
a first draft before I really knew what the point of the thing was.
Then I went back and rewrote it with those insights in mind. We were
actually starting our books around the same time and I remember being
envious that you had more time for yours (mine needed to be out before
the 2004 election). But enough about me...

Re the title, I think all those potential meanings come across, though
for me the dominant one is the idea of a programmer working so hard
that he (or she) is seeing code in their dreams, like the way one used
to see tetris in the rivers of white space on a book page or on one's
eyelids when falling asleep.

Anyway, you've assiduously caught up with me, so I can no longer coast
on my original spate of questions. So now I'll steal a question from
our host Bruce. He said, "I'm struck by the interweaving of a
more-or-less general theory of software development in amongst the OSAF
and other test cases. It's in the end, a very rich book for this," and
Scott I know that some readers have suggested that Chandler is such a
special case that you can't generalize from it, or Chandler has failed
so it's not a good case study, and so on

Is there more to this story than "what happened to Chandler"?
  

    
scott, when i heard you were working on this project,
i immediately thot of 'the soul of a new machine' and
'the inmates have taken over the asylum'. did you read
these are part of yr prepwork for the project? or avoid
them, so as not to contaminate your own vision?
  

    
[Paulina slipped while I was answering Christian, so I'll return to her 
question, but first, answering post 5, " Is there more to this story 
than 'what happened to Chandler'?"....]

I certainly hope so! It's funny, I always knew that trying to do *two* 
things at once in the book -- tell a story AND answer a question -- was a 
risk. If I didn't play it right, it would just be a mess. And even if I 
did pull it off, inevitably the readers who loved the story might be 
bummed that I was departing from it to explore some history or background 
or theoretical question; and the readers who loved the history and the 
theory and the quest for answers might find the story a distraction. That 
Bruce and others have found the result rich tells me that there's some 
group, at least, for whom I hit a good balance. 

You know, even though this was my first book, I've been writing all my 
life, I'm 47 now (I was 44 when I got the book deal), and I was 
determined, at this stage of my game, to attempt something difficult -- 
not for stunt value, but to hold my interest and, I hope, a reader's.

So it was always "more than just Chandler." The book is structured around 
each phase of the work at OSAF that I observed -- from choosing a 
programming language and toolset to building a back-end to designing an 
interface to figuring out how to manage the team and schedule the work, 
and so on. I tell the story of what happened at OSAF and then dive into 
the "more than" stuff: the history of that activity, some examples of 
other approaches, ideas people have had to solve that piece of the problem 
(and why those ideas have or haven't changed things for the better), and 
so on.

In my chapter on reuse, for instance, I have a long discussion of the 
dream of a "Universal Snap-In Software Kit," exemplified in the work of 
Brad Cox, and I ponder why it is that software developers often seem to 
prefer to write new code from scratch. Or in my chapter on programming 
languages, I discuss the rivalry between the Perl and Python camps, with 
reference to the different personalities of those languages' inventors, 
and I use that as a way in to the whole programming-language-as-religion 
thing. I wanted the book to be an accurate and entertaining portrait of 
programming culture. Who are the people building the stuff our 
civilization runs on, and what are they like? Chandler gave me tons of 
great opportunities to go down those side paths. 

I have to say, there aren't too many actual readers of DREAMING IN CODE 
who've suggested that Chandler is too special a case to generalize from, 
etc. There's certainly a lot of comment out there on Slashdot and such 
from people who *haven't* read the book who just dismiss the OSAF team as 
a bunch of fools. But those who've read the book, I think, see that the 
Chandler developers are, for instance, wrestling almost from day one with 
the question of whether the client-based approach (their original choice) 
or a web-based application would be the best route. They were totally 
aware of these issues and grappling with them throughout. You can 
certainly criticize some of the decisions they made, but I don't think 
anyone can write off their story as irrelevant, simply because thy had so 
many problems. And, as I repeat whenever I get the opportunity, while 
Chandler is certainly not a success as of this moment, I don't believe it 
can or should be written off as a failure -- anymore than Mozilla should 
have been written off as a failure in the pre-Firefox days.

It would have made a more conventionally "good" book if I had a story of 
triumph to tell. I think that's what a somewhat cranky reviewer in the 
Financial Times wanted: a code-slinging "Rocky" of some kind. For me, 
though, the difficulty and the incompleteness of the Chandler story -- 
while maybe less satisfying for the reader seeking a traditional payoff 
ending -- ended up being apt and true to the subject. 

Projects have problems. They take longer than planned. They face tough 
choices about scaling back their ambitions. This isn't atypical. This is 
the norm. This is reality. And I've always clung to the belief that 
reality is interesting. Trying to portray reality is worth one's time. 
  

    
As for Paulina's question: "The Soul of a New Machine" certainly hangs 
over my project as an inspiration and something of a problem. An 
inspiration simply because it's such a great book, it's still fun to read, 
it introduced a whole generation to the idea that the story of computing 
is worthy of attention, it's not just plumbing, it's smart people 
struggling with difficult creative problems. A problem because, you know, 
Tracy Kidder basically lived with the people he wrote about, and he told 
the story in a kind of personal way that I was never going to be able to 
achieve here. So if people were expecting that from DREAMING IN CODE I was 
going to disappoint them. Also, it's 25 years later, our whole 
relationship to computing is way different now -- it's not a strange new 
world for us to be introduced to, it's part of our lives, and we know it 
as a tangle of problems that are *our* problems, too, not just strange 
dilemmas facing somewhat strange guys at companies in places like Route 
128 and Silicon Valley. 

Anyway, yes, I reread THE SOUL OF A NEW MACHINE in 2001 or 2002 as my book 
was gestating in my brain, and then put it down and didn't look at it 
again. 

Alan Cooper's THE INMATES HAVE TAKEN OVER THE ASYLUM is a wonderful rant 
that I refer to in a couple of places in DREAMING IN CODE -- so yes, I 
read it, too. It's a great argument about the problems with software, and 
I went and had a great interview with Cooper after reading the book, but I 
found his argument difficult to connect with my narrative, and I tucked 
the interview away for possible later use. I'd still like to see if I can 
turn it into a separate Salon piece. He's got some fascinating insights, 
but I just couldn't figure out how to get them into my book, and I figured 
he'd already had the chance to present his perspective at book length! 
  

    
yeah, i always thot kidder's book was interesting for some
inobvious ways:
- how do you write about technical stuff and make it interesting
without heroizing everyone and making them larger than life?
(the FT 'rocky' problem you refer to). i think kidder is
guilty of this, but it makes for entertaining reading
- and, if i remember correctly (i read that book
LO so many yrs ago), the final product wasnt some amazing
paradigm-smashing thing --- and DG is obviously not around
any more. so, in its way, not that different from
chandler. but kidder sort of cheater by making us fall
in love with his team and their challenges...

scott, are you noticing a difference between how
the non-technical community vs the technical
community is responding to your book?
  

    
I love the digressions in the book, btw. The analogy may be strained
but in an odd way they remind me of Moby-Dick, with its tangents on
ropes, sailing, whales, weather, and so on.

Early on in reading the book I had a moment of delight when I realized
that you were systematically explaining most of the shared "folkways"
of computer geeks, if I can call them that. After years in the geek
blogging world I was aware that most of these metaphors and ideas and
memes were commonplace among alpha nerds but completely greek to
ordinary people. Here I feel like you have opened up an fascinating
world to outsiders by explaining these things in humane terms.

One thing that can make that sort of task difficult is the fact that
once you learn something it's easy to forget what it was like before
you knew it, or to empathize with people who have not yet heard of or
internalized it. Teachers have to deal with this all the time.

Was that a challenge for you, discovering the fascinating edge between
what you knew and what your readers might not?
  

    

(NOTE: Offsite readers with questions or comments may send them to
 <inkwell@well.com> to have them added to this conversation)
  

    
Paulina asked above about the difference between responses from technical 
and non-technical readers: Since the book has been out under a month now, 
most of the reactions to date are from the former. My hope of course is 
that over time the book will find its way to more of the latter. 
Technically-oriented readers are my early adopters, though! Inevitably 
among them there is a range of reaction, with a significant number of 
people who -- understandably -- are looking for answers, guidance, 
bullet-points or "take-aways." And DREAMING IN CODE is probably 
frustrating to them. I'm hoping that at least some will come looking for 
quick fixes but go away with a richer or more subtle understanding of 
their field.

My dream for the book is that developers might read it and feel that their 
work has been represented faithfully and entertainingly enough that they 
might want to hand it to a relative or friend and say, "Here, read this if 
you want to understand what I do all day" -- or, "If you want to know why 
you sometimes see smoke rising from my forehead, this might help."

Christian, I'm delighted that you mentioned "Moby Dick." No, I don't think 
Mitch Kapor is an Ahabic figure, he's quite the opposite in leadership 
style. But in mixing up storytelling and descriptive material I definitely 
had that model in mind. And I loved Melville's chapters on whaling at 
least as much as the ones that furthered his tale. In my English studies 
we called this the "encyclopedic narrative." It actually goes back to the 
epic poetry tradition. (Attentive readers will notice that I begin the 
book *in medias res*.) This is what I told Jim Fallows when he asked me 
(while talking to me about a piece he was writing about Chandler) whether 
DREAMING IN CODE was comedy or tragedy. I puzzled for a minute, then said, 
"Neither -- it's an epic!"
  

    
> Was that a challenge for you, discovering the fascinating edge between 
what you knew and what your readers might not?

Definitely a challenge to make sure that my immersion in all things Web, 
which has been total since late 1994, didn't make it impossible for me to 
see things about software and the programming field through the eyes of 
someone to whom it was all new. Hard to know if I succeeded there -- I'll 
need to see how readers react. I do have a lot of experience, going all 
the way back to my Examiner days -- where, as I recall, I started out 
having to define the World Wide Web as "the graphical portion of the open 
global Internet" each time I mentioned it -- at introducing complex 
technical subjects to a wider audience. I've always tried to do so 
accurately but without talking down to people or simplifying to the point 
of meaninglessness. One problem I found in reading popular accounts of 
programming was that the resort to metaphor was sometimes so total that it 
crowded out actual understanding of the thing the metaphor was supposed to 
explain. We've seen this in writing about technology with stuff like 
"information superhighway." In descriptions of programming, you'd get 
people using construction metaphors and transportation metaphors and 
sometimes they'd get so elaborate they'd take on a life of their own and 
become distracting rather than illuminating. Of course if you're Neal 
Stephenson ("In the Beginning Was the Command Line") you can pull off as 
elaborate a metaphor as you want...
  

    
I've been looking forward to getting a copy of this book for quite some 
time, and this discussion makes me even more eager.

One of the questions that comes up for me is whether the Chandler 
situation is similar to many humongous projects that never yield results. 
I'm thinking in particular of two Apple-IBM collaborations from about 10 
years ago that churned through ungodly amounts of time and resources and 
were eventually dropped, or for that matter, the related issue of Apple's 
next version OS before Jobs came back and they purchased Next and just 
adopted that.

So, are there generalizations out there? Say, if you try to solve to many 
problems at once you most likely end up solving none?
  

    
So what did you learn from watching the Chandler team struggle with
their grand vision? What surprised you? What expectations did you have
going in and were they met or confounded?
  

    
Ari, I think there are some big differences between Chandler and projects 
like the Apple/IBM/Taligent/Kaleida stuff (which was very much related to 
the effort to upgrade or replace the old Mac OS). With the latter, before 
you even begin to get to the technical and design issues, you had to face 
the fact that you had two big companies trying to steer the same boat, and 
their interests and cultures and wishes were inevitably going to clash. 
Paralysis ho! The Chandler team included some veterans of those efforts, 
in fact. Chandler has a single chief funder and a single project 
leader/visionary, so it doesn't face that sort of dual loyalty trouble. 
 
But for sure, the larger point is, be extremely careful with your 
ambitions. At one point in DREAMING IN CODE I quote Linus Torvalds' 
argument that one should never ever set out to solve a big problem or set 
of problems -- always start small, he advises. That's certainly one way to 
avoid trouble, but it's extremely difficult advice for smart, ambitious 
people to take! 

Christian, I went in without too many expectations, beyond the simple one 
of assuming that I was going to be observing talented, experienced people 
trying to do something interesting, where the outcome was not at all 
predetermined. I very consciously said to myself, at the start of my work, 
"Don't write the ending in advance!" You know, I've always been a deadline 
writer -- I used to write overnight theater reviews, where I had 2-3 hours 
to try to analyze some new play, judge the production and entertain my 
readers, and do that all to fit a certain number of column-inches that had 
been chosen *before I'd seen the play.* Under such conditions you develop 
a habit of thinking ahead -- how am I going to end this piece? where am I 
aiming the arrow of my lead so that the motion will carry me through to 
where I want to be at the end?

Writing a book for the first time, I told myself, don't do that! You've 
got the opportunity, finally, to witness a story and watch it unfold 
without imposing an order or framework on it too early. Of course 
eventually that's what a writer has to do, but I was determined to wait as 
long as possible.

If I was surprised at anything as I watched the work at OSAF, it was how 
this group of developers ended up reinventing and  renegotiating so much 
of the process of their teamwork. I realized that software development is 
often like the movie industry in this regard. Unless you're at a place 
like Microsoft with its own vast army of developers and its own internal 
traditions of project management and team coordination, software 
development is remarkably like the movie industry: Trained, experienced 
people hop from project to project (or startup to startup), bringing their 
own ideas of best practices with them, and at the beginning of a project, 
there's a lot of work to be done just feeling out stuff like, how exactly 
are we going to collaborate? how do decisions get made? how are we going 
to measure our progress? who takes responsibility if progress isn't 
happening?

So I think that any time you have a team that already shares an 
understanding of this stuff -- whether through corporate tradition or 
community-building or simply because the individuals have worked together 
before -- you're way ahead of the game. 
  

    
Hi Scott, hello all. I just finished the book this week, but like
Christian I've actually been looking forward to it for many years.

In those years my own mix of work has involved more and more
programming (and more and more Python, specifically), and the book
touches on so many things I've thought about both as a programmer and
as a writer that it's hard to know where to start.

One thing I appreciated was that you didn't pre-empt earlier parts of
your story based on later developments. Naturally, as I sat here in
2007 reading about OSAF's 2002/2003 plans to make a networked PIM, I
thought, "They're not doing this on the web! They're doomed! Why isn't
he talking about that?" You do talk about it, of course, but later,
after walking us through those days when Ajax was a character in the
Iliad, not a web technology.

How hard was that to do? And if Chandler had met great success with a
1.0 release during the time you were writing, how might those early
chapters -- presuming they covered roughly the same period in both our
universe and the Chandler-wins alternative universe I'm positing --
have been different?
  

    

Scott, your book was a great read for this non-programmer.  I've got
<lee> reading it as well but not sure if he'll make it to this discussion.
  

    
>At one point in DREAMING IN CODE I quote Linus Torvalds' 
argument that one should never ever set out to solve a big problem or
set of problems -- always start small, he advises. That's certainly one
way to avoid trouble, but it's extremely difficult advice for smart,
ambitious people to take! 

What? and end history as we know it!!

We need to keep smart, ambitious people busy with something or else we
will really be in trouble. (Then, again, there were those signers of
the Declaration of Independence. A fluke, maybe?)
  

    
Maybe. But if the signers of the Declaration of Independence had been  
programmers, it's possible that they might have gotten bogged down 
figuring out which programming language to use, which version control 
system and bug-tracker to adopt, and what framework to employ! Torvalds' 
advice is not necessarily one size fits all human endeavor; it's a caution 
in a particular field where big ambitions too often lead into a bog.

Lendie: Thanks for the non-programmer accolade. I'm going to keep 
accumulating that sort of data :-) 

Paul: The whole "web app or not?" question as it relates to Chandler is 
fascinating; it could be a whole book in itself. I tried hard not to let 
hindsight govern the telling of the story; that would not only be unfair 
but, I think, less interesting. The bigger question for Chandler, and 
indeed all of us in the field, is whether the shift to Web applications -- 
which I'm a full believer in, and which I think is well underway and 
pretty much unstoppable -- is a somehow irreversible transformation, or 
whether it's simply a particularly violent swing of the 
client-or-server-side pendulum. The whole industry has cycled several 
times through periods when the orthodoxy was "do as much as you can in the 
client" to other periods when it flipped the other way. We have some very 
strong incentives today to do as much as possible in the browser. That's 
playing out now. But I do think at some point we're going to say, "OK, 
this is great, but what have we given up?"

For instance, as I say in the book, I use Ecco as my PIM. One of the 
things that I love and simply can't give up (yet) is its fluid outlining, 
where you can pretty much just start typing anywhere in the interface. 
(Sort of like a spreadsheet.) Web-based PIMS have come a long way just in 
the time DREAMING IN CODE took to write (I was playing last night with 
Tiddlywiki -- that's a strange and fascinating warping of wiki editing and 
outlining!), but none of them can yet take in my data as effortlessly as 
Ecco does. Either we'll find ways to push Web apps further and further in 
that direction -- until they resemble client-side apps so fully that the 
difference becomes meaningless to the user -- or at some point we'll stop 
and say, "Hey, maybe a system that lets me work on the same data in a 
browser AND in a client is the best approach." (Gmail hooked into POP, 
which is how a lot of people I know use it, is one version of this.) And, 
you know, that's exactly what Chandler is now closing in on.

Sometimes in the software world (and that of hardware, too, for that 
matter), if you miss your mark and come in to a market late, you're 
screwed. But if you fall *really* far behind, you turn out to be just in 
time for the next turn of the wheel. In a way that happened with Firefox; 
a Firefox in 2002 might've had a hard time. But it came along right at the 
moment when developers were starting to rely more on Javascript-y magic 
and AJAX and those things dovetailed with Firefox in a way that IE still 
has a hard time matching. So Firefox's "lateness" turned out to be a plus. 
In the same way, I think it's *possible* Chandler's rich-client with Web 
interface approach could fill a niche that no one even imagined in 2002 or 
2003.
  

    


It's always interesting when there is 1 master (Kapor) and 1 funder (Kapor)
vs. ventures that have to seek funding and are more fluid in the top most
leadership.

There were moments in reading DiC in which I began to think about Ted Nelson
& Xanadu not so much because they are alike but because Chandler has had
such a permeable time frame.  Obviously Mitch & Ted are practically opposite
personalities yet it's clear they both have specific passions they want to
see realized.

What do you think can keep Chandler from becoming Xanadu?
  

    
(Not to step on Lena's question, but Scott, I wanted to let you know
that your book also inspired me to revisit other books on software --
on my desk now I've got _The Mythical Man-Month_, _The Pragmatic
Programmer_, and Knuth's _Literate Programming_.)
  

    
I, too, have been looking over some of those things -- prompted by Scott's
book club kind of thing. (Which I'd say more concerning if I were willing to
go find a url right now, but about which perhaps Scott will speak and save
me the trouble.)

Two reminders, in my hostly role:

  o   for more about our guest author, or to buy the book in order to join
in, please visit http://www.well.com/conf/inkwell.vue/

  o  questions or comments from off-site readers may be e-mailed to
inkwell@well.com for us to post here
  

    
It's great to hear that I've sent some developers back to their history! 
There's a lot there. The book club thing Bruce refers to is called Code 
Reads, on my personal blog at 
http://www.wordyard.com/category/code-reads/. It has been sadly neglected 
for several weeks because of the book launch but I intend to return to it 
very soon, hopefully even this weekend or early next week. It's less 
book-focused than article-focused, because it seems understandably easier 
to get people to read a shorter article than an entire book.

As for Lendie's question about Xanadu: My memory of that project is a 
little dim, it's been years since I heard Ted Nelson talk about it, but my 
understanding is that he has always had a vision for a particular kind of 
hypertext environment that is in some ways richer and more complex than 
the Web (for instance, links are two-way), but that he's never been able 
to get past the chicken/egg problem of either (a) developing something 
compelling enough that people flock to it or (b) getting enough people to 
flock to something that's only partway there that the vision gets carried 
along by the flock.

Chandler's issues have been quite different; I think Kapor is much more of 
a pragmatist, he understands what's needed to spark an adoption cycle, he 
just has yet to get Chandler close enough to that point. (This spring's 
release will be the next significant test.)

The history of the Web's success vs. Xanadu suggests that people will 
gladly embrace a "just good enough" solution to a problem if it's easy 
enough and accessible enough and lets them play. When I saw  the Web 
through Mosaic in summer of 1994 I didn't think, "Wow, that's great 
software," because, you know, it was pretty clunky at that point; I 
thought, "Wow, I can build my own page!," and then I thought, "If I can do 
it, tons of other people will too, and that will be even more fun." And 
that made learning HTML seem worth the (not so huge) time investment.

So the lesson for software projects might be, show people how they can do 
something new and fun or useful, make it accessible, don't even think 
about making it perfect. The Web itself turns out to be a great platform 
for developing software that way, and that's one reason Web-based 
applications are so popular today.
  

    
I'd like to ask you to talk a bit about the GTD (Getting Things Done)
personal task / project / productivity system. I was just talking to
someone yesterday about how there's a bit of a geek cult around this
book and its methods....