Sophie and Software Development

Permalink for this paragraph 0 MKG: Many teachers want to teach their students to create multimedia projects, but they are afraid that they’ll wind up teaching the tools (or, worse, they don’t know the tools themselves, much less how to teach them). When you were working on Sophie, were you trying to address that problem? How can an authoring environment like that open up new possibilities for students?

Permalink for this paragraph 0 BS: When we were growing up, teachers didn’t spend much time teaching us how to use pencils and pens (basic tools of expression) — rather they concentrated their efforts on teaching the craft of writing or doing history. Our original goal in building Sophie was to build a tool that enabled people to assemble complex multimodal, multi-layered texts without needing to write code or learn complicated authoring tools such as Director or Flash. Although Sophie 1.0 never was never released, a few teachers used it extensively and we saw really brilliant multimedia projects built by students with only a few hours of instruction in the tool itself.

Permalink for this paragraph 0 MKG: Why didn’t you release Sophie 1.0?

Permalink for this paragraph 0

BS: There’s a long list of related reasons, but the main one, and I’ll take responsibility for it, is that we tried to do so much in version 1.0, that by the time we were almost ready to bring it to market, the goal posts had moved and we just didn’t have the right product at the right time. I realize now that the whole way we went about designing and implementing Sophie was fatally flawed. We tried to design something that was “perfect,” and that turned out to be an impossibly difficult job. If we had taken one tiny subset of Sophie, put it out there and called it a beta, and improved it over the course of time, we would have been in much better shape. The reality of book publishing is that you have to have the manuscript 100% right and complete before it goes to the printer. As a publisher, I learned to live with the “get-it-right-the-first-time” reality of print, but it’s a completely wrong model for software development in the era of the digital network, where the goal is to get out a good-enough first version and then iterate and improve as fast and as often as you can.

Permalink for this paragraph 0 Let me give you an example. Sophie was originally conceived as a rich-media authoring tool. A couple of years into the project, partially based on the experiments the Institute was doing with networked books, we realized that Sophie HAD TO HAVE a social component which allowed people to carry out a conversation in the margin. This impulse was correct, but instead of waiting for version 1.x or 2.0 to implement commenting, we made the disastrous decision to make it a fundamental feature of 1.0, which of course added untold months of development.

Permalink for this paragraph 0 Sadly, I’m doubtful that Sophie will ever reach its goal. There’s a terrific group of developers in Sofia (Bulgaria) who are continuing work on Sophie 2.0, but I’m afraid that having inherited the legacy conception of version 1.0, they won’t be able to marshall the resources necessary to release a compelling tool set.

Permalink for this paragraph 0 MKG: So you haven’t been involved with the version of Sophie that is being developed at USC?

Permalink for this paragraph 0 BS: No, I left the project just before the Sophie 2.0 work started.

page 10