Inkwell: Authors and Artists

    
I may have said this at the outset or I may not have, but Scott one of
the things that really struck me about your book is that in it you
catalog most of the interesting trends, ideas, dare I say memes? that
have flourished on the web and in the software-design (broadly taken)
world in the last decade or two and in so doing I think you've managed
to nicely bridge the gap between those of us who are more or less
immersed in geek think and those who are not but who are capable of
being intrigued by these developments.

Back around 2002-2004 when I was blogging heavily about blogs
themselves and about the RSS wars and such, friends and family would
visit my site and confess that it was all g(r)eek to them. Now I feel
like I could give some of those folks your book and say "this is what I
was talking about."

For that service alone, you should be commended.

I know we're nearly out of time here, but I wonder if you might be
able to spare a few moments for a really brief historical look at the
history of Salon.com - how it was launched, to what extent it was (as
lore around here suggests) incubated on the Well, and so on. You were
there! (And that time period is beginning to enter the
first-draft-of-history stage.)
  

    
Yow, that's another two weeks of posts at least :-) So I'll just hit a few 
quick points.

First, there was a private conference on the Well in 1995 that some of us 
used to do some planning for Salon. <hlr> -- who David Talbot and I knew 
(he'd been writing a column for us at the Examiner for several years) and 
who David had brought in as an early adviser -- encouraged this, I think, 
and I thought it was a great idea. If I recall correctly, Andrew Ross took 
to it as well. Laura Miller, also, I believe, had been on the Well and so 
it was easy for her to participate. I was all for anything that would push 
this group of Net-virgin newspaper people to do their work in the 
environment that their new publication was going to inhabit. But David 
never really got into the Well and he was the centerpiece of the 
operation. So it quickly became apparent that the Well conference, while 
useful for some brainstorming, was not going to be the core of the 
planning.

The history of Salon spans a dozen years now, and I have vast quantities 
of memories and anecdotes and rear-view-mirror analyses, and it's really 
hard to know where to begin. Maybe if you can toss a handful of more 
specific questions at me that would help!

One thing I connect with the themes of DREAMING IN CODE from the early 
days of Salon is this: I'm a methodical person; one reason I prefer 
writing to, say, talking on the radio is that you get to review, edit, and 
fine tune your expression. So I really thought we should take a lot of 
time to plan stuff and perfect everything before we took Salon live. I was 
the only person of the original launch crew of Salon who'd ever actually 
created a Web site before, and I thought, you know, there are a lot of 
loose ends that we'd need to tie up. 

David, on the other hand, thought it was most important to get Salon up on 
the Web fast, even if we didn't know exactly what we were doing. And he 
was totally right -- not only from the perspective of a business, which 
wants to get out ahead of the competition, but also simply in terms of the 
nature of the medium. Even though I was in theory the one who "got" the 
Web best, David -- print-magazine background notwithstanding -- understood 
in his gut, far better than me at that point, that this was a world where 
the best course is to put stuff up in a partially finished state and learn 
as you go along. 

We didn't know to call it "iterating." But same concept.
  

    
I just wanted to give a hearty thanks to both Scott and Christian
for a great interview.

There's a nice write-up on Scott's book in the dead-tree edition
of today's Seattle Post-Intelligencer.   As soon as a link goes
up on their website I'll put a reference in here so that those
of you who aren't lucky enough to live in the lovely Pacific
Northwest can still read it over.

Thanks guys!!
  

    
Yeah, thanks to both of you, and to Ted too for stopping by. Scott, it's
been fun having the opportunity to grill you on the details behind the book.
Good luck with it, and with your own code dreams at Salon!
  

    
Thanks!  This has been a great read to accompany the book.
  

    
Thanks, Scott, for fielding such a wide range of questions with
aplomb.
  

    

Yep, this one was a lot of fun!
  

    
Thank you!
  

    
That review was in the Seattle Times, not the P-I. (it's a joint Sunday
paper, but all but four pages come from the Times).

Here's the oonline version:
http://seattletimes.nwsource.com/html/books/2003608118_dreaming11.html
  

    
Thanks to you all -- this was a treat.

If you just can't get enough of this topic, I'm scheduled to be on KQED 
Forum tomorrow (Tuesday) at 10 AM to talk about the book with Michael 
Krasny. Maybe someone will call in with the solution to all of the 
software field's problems!
  

    

It's up:

  http://www.kqed.org/programs/program-landing.jsp?progID=RD19

Now where are those headphones...
  

    

I finished the book a couple of days ago. One of the things it reminded me
of is that people often find their own uses for software, regardless of
what the designers think the most important uses are.

My first PIM, to the extent I ever have used one, was in fact Mitch Kapor's
On Location, from On Technology. It indexed my entire hard drive, and not
only let me find info I'd misplaced, but it also helped me make connections
between files I'd not otherwise have made. A major example -- when other
folks and I were tracking down the true story behind Marty Rimm's fraudulent
cyberporn "study," it was On Location that enabled me to quickly determine
where Marty had gotten the information he supplied to Time magazine and
to Congress.

(I happened to have the index files from the Amateur Action BBS case on
my hard drive, and it turned out those files had unusual character
strings that showed up in Marty's writings and in the papers and
internal memos produced by the religious right antiporn activists.)

Sadly, Apple's Spotlight doesn't do the job nearly so well.

So, while PIMs ostensibly help you organize and find information you
already know about, they may also help you make connections you'd not
otherwise have made and find new info as well.

 
  

    
Good points, Mike.

Really, that issue of "the street finds its own uses for things" can turn
into a problem *during* development if the team thinks about it too much. If
you're drawn away from an initially well conceived spec towards making more
of a Swiss Army knife, direction is tough to find.

So, I've been quoting "build half an application, not a half-assed
application" in my own work environment, which is academic administration,
rather than software development.
  

    
That's fascinating about On Location, Mike. I paid close attention 
recently to the similar saga of how that bizarre story of the British 
pianist whose husband (I guess) was grabbing old recordings and issuing 
them under her name was detected: someone's music player software 
"misidentified" (actually, correctly identified) the plagiarist pianist's 
recording as somebody else's recording, based on its digital fingerprint.

Our tools do different things than we imagine! Sometimes that's a pain, 
sometimes it's valuable. On my (highly limitied) lecture circuit I've been 
touting Brian Eno's philosophy of ignoring device instructions t o 
explore creative use of tools and instruments, and also suggesting to 
developrs that they look at every bug and take just a quick second to ask 
whether it might be a feature instead, before fixing it. In most cases the 
answer will be "no," but the rare "yes" may be quite valuable.
 
  

    

On Location was such a valuable tool for me that when On Technology stopped
selling and supporting it I amassed a bunch of data and tools that enabled
me to keep the software functioning all the way through OS 9.x.  For a while
I reduced it all to a diskette, which I then zipped and gave out to other
people who happened like me to be big fans of the program.
  

    
>Our tools do different things than we imagine!<

If only we could get this message across to the government among other
human institutions. 
  

    
I just finished reading "Dreaming in Code". It's a great book. I'm not 
sure it speaks to non-geeks the way that, say, "The Soul of a New Machine" 
did, but it certainly speaks to me. I feel energized and inspired.

What I'm most curious about, though, is the book's ending. It's as though 
the Chandler project provided an excuse to write, but over time, as 
Chandler trundled slowly on, the question of software development takes 
over, such that the real theme of the book seems to be "how do we develop 
complex software and is it even possible?" Those questions seem no more 
answerable than any other existential questions, but I'm curious, Scott, 
how you felt about the book morphing into something else, or, by the time 
you had to turn your notes into a book, was it already clear that this was 
what you wanted to say?
  

    
Hi, Ari -- thanks for the kind words. My idea from the very beginning was 
to tell the story of the making of one piece of software (actually, the 
earliest idea was to tell several projects' stories but that quickly came 
to seem like an overload for both me and the reader) and to use that 
narrative as a way to address a series of fundamental questions about the 
process of making software -- all clustering around the central one, why 
is it so hard to make software well?

So for me there was no morphing of the book from one thing into another. 
What may have given you that feeling was the extended detour I took from 
the Chandler saga in chapters 9 and 10, where I review the methodologies 
and the various visionary notions about how to change the field. Viewed 
from one angle I'm sure this can be seen as a structural flaw in the book; 
I felt that, with all the pressure and frustration built up by Chandler's 
long delays, the reader might actual find it a refreshing break to wander 
afield for a while before returning to Chandler. 

And then of course there was the whole issue of ending the book before the 
story was over, which I believe I've already talked about at length higher 
up in this thread...

So I guess I'd just say that the dual structure -- part narrative, part 
essay -- was in the plan from the start. I hoped that any unevenness in 
the execution would be perceived as pleasing variation. But I've certainly 
gotten a wide range of responses from readers on that -- some found it 
appealing, others confusing; some wanted more essay and less Chandler, 
some just the opposite!
  

    
The one big issue I have with the book is that I don't think that most 
software engineering is as open-ended or difficult to manage as Chandler 
was/is. I've spent much of the last 10-15 years working on website 
development, and most of the time, we can set pretty reasonable schedules, 
with known resources and a mix of known/unknown features, and be pretty 
good at delivering on time, on budget, in scope. Those of the sorts of 
projects that formal Project Management can help considerably (or that can 
often be addressed with equal success by agile development methods).

The development problems you describe arise most definitely when one is 
trying to create something big and new. In addition to the engineering 
issues surrounding how to best build something still not understood or 
defined, there are tremendous political and cultural issues - how (and how 
successfully) some subset of the original vision turns into a usable 
product depends so very much on how good people are at negotiating with 
each other, what resources are available, with what constraints, and in 
communicating/building that shared understanding that means that everyone 
is seeing the same project in their heads.

But that was no less true for Boston's Big Dig (a recently "completed" 
project that buried a highway that passes through downtown Boston, which 
has so far killed one person traveling through and which seems to have 
some scary defects) than for Chandler.

That doesn't take away from the issues surrounding making software 
development work better, or finding new techniques to make 
ever-more-complex programming feasible, but I think fewer of those issues 
are unique to software development.
  

    
I'm curious whether a dynamic like the following plays any significant role
in group projects.

In working on a little project of my own, using a C-based language in which
array indices begin with zero, I decided that in one particular case it
would be better to skip the zeroth value and begin with [1], to simplify the
code that makes use of the array.  It wasn't but a few minutes before a use
for the zeroth value had occurred to me, and before catching myself in the
act, I'd mapped out a design that would have violated the least surprise
rule of interface design, by providing an unnecessary means of disabling the
feature associated with the array, resulting in the loss of the data in the
array.

Basically, what I did, was to say "here's something I could use, now what
can I use it for" and to allow the answer to that question to grow beyond
the bounds of the overall design.