The WELL: inkwell.vue.293: Scott Rosenberg, Dreaming in Code

#95: John Payne (satyr) Wed 4 Apr 07 12:12

Wed, 04 Apr 2007 12:12:00 PDT

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. [Read entire topic]

#94: Ari Davidow (ari) Fri 30 Mar 07 06:55

Fri, 30 Mar 2007 06:55:00 PDT

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. [Read entire topic]

#93: Scott Rosenberg (scottros) Thu 29 Mar 07 20:50

Thu, 29 Mar 2007 20:50:00 PDT

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! [Read entire topic]

#92: Ari Davidow (ari) Wed 28 Mar 07 21:01

Wed, 28 Mar 2007 21:01:00 PDT

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? [Read entire topic]

#91: Cupido, Ergo Denego (robertflink) Sat 24 Mar 07 03:12

Sat, 24 Mar 2007 03:12:00 PDT

>Our tools do different things than we imagine!<

If only we could get this message across to the government among other human institutions. [Read entire topic]

#90: Mike Godwin (mnemonic) Fri 23 Mar 07 20:46

Fri, 23 Mar 2007 20:46:00 PDT

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. [Read entire topic]

#89: Scott Rosenberg (scottros) Wed 21 Mar 07 13:31

Wed, 21 Mar 2007 13:31:00 PDT

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. [Read entire topic]

#88: virtual community or butter? (bumbaugh) Wed 21 Mar 07 09:04

Wed, 21 Mar 2007 09:04:00 PDT

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. [Read entire topic]

#87: Mike Godwin (mnemonic) Tue 20 Mar 07 07:21

Tue, 20 Mar 2007 07:21:00 PDT

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. [Read entire topic]

#86: Gail Williams (gail) Thu 15 Mar 07 10:37

Thu, 15 Mar 2007 10:37:00 PDT

It's up:

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

Now where are those headphones... [Read entire topic]