Christian Crumlish (xian) Thu 8 Mar 07 10:39
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.)
Scott Rosenberg (scottros) Thu 8 Mar 07 14:43
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.
Hal Royaltey (hal) Sun 11 Mar 07 22:57
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!!
Paul Bissex (biscuit) Mon 12 Mar 07 05:42
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!
Elaine Sweeney (sweeney) Mon 12 Mar 07 07:52
Thanks! This has been a great read to accompany the book.
Christian Crumlish (xian) Mon 12 Mar 07 08:47
Thanks, Scott, for fielding such a wide range of questions with aplomb.
Gail Williams (gail) Mon 12 Mar 07 10:31
Yep, this one was a lot of fun!
Howard Berkey (howard) Mon 12 Mar 07 10:37
John Ross (johnross) Mon 12 Mar 07 14:45
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
Scott Rosenberg (scottros) Mon 12 Mar 07 22:33
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!
Gail Williams (gail) Thu 15 Mar 07 10:37
It's up: http://www.kqed.org/programs/program-landing.jsp?progID=RD19 Now where are those headphones...
Mike Godwin (mnemonic) Tue 20 Mar 07 07:21
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.
virtual community or butter? (bumbaugh) Wed 21 Mar 07 09:04
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.
Scott Rosenberg (scottros) Wed 21 Mar 07 13:31
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.
Mike Godwin (mnemonic) Fri 23 Mar 07 20:46
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.
Cupido, Ergo Denego (robertflink) Sat 24 Mar 07 03:12
>Our tools do different things than we imagine!< If only we could get this message across to the government among other human institutions.
Ari Davidow (ari) Wed 28 Mar 07 21:01
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?
Scott Rosenberg (scottros) Thu 29 Mar 07 20:50
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!
Ari Davidow (ari) Fri 30 Mar 07 06:55
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.
John Payne (satyr) Wed 4 Apr 07 12:12
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 , 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.
Members: Enter the conference to participate