My first commit to the SocialCalc project was from June 2009, followed by four months of intensive hacking before we delivered SocialCalc 1.0 at October 19th, on the 30th anniversary of the initial release of VisiCalc.

While it was a brief period compared to the three years it took for wikiCalc to evolve into SocialCalc, the experience of collaborating with my colleagues at Socialtext under Dan Bricklin's guidance was very valuable to me, and I'd like to share some lessons I've learned during that time:

In his book The Design of Design, Fred Brooks argues that when building complex systems, the conversation is much more direct if we focus on a coherent Design Concept, rather than derivative representations.

According to Brooks, the formulation of such a coherent design concept is best kept in a single person's mind:

Since conceptual integrity is the most important attribute
of a great design, and since that comes from one or a few
minds working uno animo, the wise manager boldly entrusts
each design task to a gifted chief designer.

In the case of SocialCalc, having Tracy Ruggles as our chief user-experience designer was the key for the project to converge toward a shared vision. Since the underlying SocialCalc engine was so malleable, the temptation of feature creep was very real; Tracy's unique ability in communicating with design sketches really helped us presenting the features in a way that feels intuitive to users.

Before I joined the SocialCalc project, there was already over two year's worth of ongoing design and development, but I was able to catch up and start contributing in less than a week, simply due to the fact that everything is in the wiki - from the earliest design notes to the most up-to-date browser support matrix, the entire process was chronicled in Wiki pages and SocialCalc spreadsheets.

Reading through the project's workspace brought me quickly on the same page as others, without the usual hand-holding communication overhead typically associated with orienting a new team member.

This wouldn't be possible in traditional open-source projects, where most conversation took place on IRC and mailing lists, with the Wiki (if present) is only used for documentations and links to development resources - For a newcomer, it's much more difficult to reconstruct context from unstructured IRC logs and mail archives.

David Heinemeier Hansson, creator of Ruby on Rails, once remarked on the benefit of distributed teams when he first joined 37signals:

The seven time zones between Copenhagen and Chicago actually
meant that we got a lot done with few interruptions.

With nine time zones between Taipei and Palo Alto, that sentiment was true for us during SocialCalc's development as well.

We often completed an entire Design-Development-QA feedback cycle within a 24-hour day, with each aspect taking one person's 8-hour work day in their local daytime. This asynchronous style of collaboration compelled us to produce self-descriptive artifacts (design sketch, code and tests), which in turn greatly improved our trust in each other.

In my 2006 keynote for the CONISLI conference, -OFun: Optimizing for Fun, I've summarized my experience leading a distributed team on implementing the Perl 6 language into a few observations. Among them, Always have a Roadmap, Forgiveness > Permission, Remove deadlocks, Seek ideas, not consensus, and Sketch ideas with code are particularly relevant for small distributed teams.

When developing SocialCalc, we took great care in distributing knowledge among team members with collaborative code ownership, so nobody would become a critical bottleneck.

Furthermore, we preemptively resolved disputes by actually coding up alternatives to explore the design space, and were not afraid of replacing fully-working prototypes when a better design arrives.

These cultural traits helped us foster a sense of anticipation and camaraderie despite the absence of face-to-face interaction, kept politics to a minimum, and made working on SocialCalc a lot of fun.

Prior to joining Socialtext, I've advocated the interleave tests with the specification approach, as can be seen in the Perl 6 specification where we annotate the language specification with the official test suite.

However, it was Ken Pier and Matt Heusser, as the QA team for SocialCalc, who really opened my eyes to how this can be taken to the next level, bringing tests to the place of executable specification.

In chapter 16 of the book Beautiful Testing, Peeling the glass onion at Socialtext, Matt explained our story-test driven development process as follows:

The basic unit of work is a "story," which is an extremely
lightweight requirements document. A story contains a brief
description of a feature along with examples of what needs
to happen to consider the story completed; we call these
examples "acceptance tests" and describe them in plain English.

During the initial cut of the story, the product owner makes a
good-faith first attempt to create acceptance tests, which are
augmented by developers and testers before any developer writes
a line of code.

These story tests are then translated into wikitests, a table-based specification language inspired by Ward Cunningham's FIT framework, which drives automated testing frameworks such as Test::WWW::Mechanize and Test::WWW::Selenium.

It's hard to overstate the benefit of having story tests as a common language to express and validate requirements; it was instrumental in reducing misunderstanding, and has all but eliminated regressions from our monthly releases.

Last but not the least, the open source model we chose for SocialCalc makes an interesting lesson in itself.

Socialtext created the Common Public Attribution License for SocialCalc. Based on the Mozilla Public License, CPAL is designed to allow the original author to require an attribution to be displayed on the software's user interface, and has a network-use clause that triggers share-alike provisions when derived work is hosted by a service over the network.

After its approval by both Open Source Initiative and the Free Software Foundation, we've seen prominient sites such as Facebook and Reddit opting to release their platform's source code under the CPAL, which is very encouraging to us.

Because CPAL is a weak copyleft license, developers can freely combine it with either free or proprietary software, and only need to release modifications to SocialCalc itself. This enabled various communities to adopt SocialCalc and made it more awesome.

Here is an incomplete list of open-source projects derived from SocialCalc:

• Drupal's Sheetnode project, with its own fork on GitHub.

• Luke Closs's initial OLPC/XOCOM port.

• SEETA's OLPC/Sugar port, derived from Luke's work.

• SEETA's Palm Pre port.

• Ramu Ramamurthy's standalone server in Scala/Java.

Examples from this chapter, including rich-text and collaborative editing, can be found on http://github.com/audreyt/socialcalc. An historical archive of WikiCalc 1.0 code is available on http://github.com/audreyt/wikicalc as well.

There are many interesting possibilities with this open-source spreadsheet engine, and if you can find a way to embed SocialCalc into your favorite project, we'd definitely love to hear about it.

Happy Hacking!

>>> Back to Home