How 5 people with 4 day jobs in 3 time zones enjoyed 2 years writing 1 book


Published on

The story of writing the JRuby book together, with lessons for freelancers, telecommuters, and remote collaborators everywhere. Speaker notes from Open Source Bridge 2011.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How 5 people with 4 day jobs in 3 time zones enjoyed 2 years writing 1 book

  1. 1. How 5 AuthorsHow Five Authors With Four Day Jobsin Three Time Zones Enjoyed TwoYears Writing One Book This is the story of a big collaborative writing project. I’m telling it for selfishreasons—not just the obvious ones like drawing attention to the book, but also forthe less obvious, more therapeutic reasons. This thing took over our lives for twoyears; after something that big, having a bit of a verbal catharsis can help bring lifeback to normal. Of course, this hour we have together needs to be worth your while as well. Soas the story unfolds, I hope you’ll feel some of the joy I felt collaborating with thesereally talented people. I hope you’ll be entertained at our setbacks—an appropriateresponse, especially considering there was no harm done and it all worked out inthe end. If you’re a freelancer, a project manager, a telecommuter, or a member of aremote team, you may find the arc of this project familiar. Perhaps some of the toolsand techniques we used along the way will be helpful to you as well.By the Numbers What do those numbers in the title mean? The five authors are: 1. Charles Nutter, one of the two co-leads of the JRuby project; 2. Nick Sieger, a core contributor to JRuby and many of its libraries (such as Rails integration); 3. Tom Enebo, contributor to JRuby since 2003 and co-lead of the project; 4. Ola Bini, a prolific polyglot programmer; and 5. Me (Ian Dees), a happy JRuby user and the only non-core team member in the group. 1
  2. 2. How 5 Authors The four day jobs are:1. Sun Microsystems (Charlie, Nick, and Tom),2. Engine Yard (Charlie, Nick, and Tom),3. ThoughtWorks (Ola), and4. Tektronix (me). The three time zones are:1. PST (me),2. CST (Charlie, Nick, and Tom), and3. CET (Ola). The two years (plus): June 2008 through October 2010 The one book: Using JRuby 2
  3. 3. How 5 Authors Before I get to the story, let me tell you about my awesome collaborators.Dramatis Personae Even though most of us knew one another, this was the first time this specificgroup of five people had undertaken a project together. Each author’s personality isof course the same across projects (one hopes), but each person’s role in thisparticular project might be something unique. My own role in this process was “the guy who talks to the editor, deals withtechnical reviewers, keeps the voice consistent across chapters, and mergeseveryone’s contributions into the work.” My first mistake in this project was notrecognizing that this was as much a project management role as it was a writingrole. So when you hear me saying things later on like, “We were spinning ourwheels,” what that really means is, “I screwed up.” 3
  4. 4. How 5 Authors The other authors’ roles emerged from their writing styles. For a chapterintroducing a broad technology, you can pair a theoretician (who has all theanswers) with a newcomer (who knows what questions to ask). For a survey ofseveral related software packages, you can send a lone wolf into the wilderness toexplore them all and bring back some insights. So, here’s a tongue-in-cheek take on the roles my collaborators played in thisproject.Ola—The Prospector Hand him a map that says something like, “Explore the Shoulda basin near theend of Testing canyon.” He’ll disappear into the wilderness for, like, two weeks.He’ll then come back with a twelve-pound chunk of gold, plunk it down in themining camp, and say, “Smelt that, baby.” Ola was off and running when the rest ofus were still tying our shoes. When things were bleakest, we’d still see the glint ofhis pickaxe swinging in the darkness.Tom—The Analyst He prefers to tackle a large problem in steps: walking around it, consideringevery angle, learning by writing code, and finding all the gotchas. Once that’s inplace, he’ll weave a compelling narrative around it. Tom doesn’t finch whenpresented with a daunting charge like, “Find out everything there is to know aboutuser interfaces in JRuby.”Charlie—The Professor He has a library of code examples at his fingertips, ready to demonstrate anynuance of the subject. His writing style is a smooth alternation between idea anddemonstration. “You may encounter obstacle X. For instance, consider thefollowing example. The solution is to do Y, as in the code below….” Charlie’sgreatest gift to the book was his sensibility. He has a great feel for when it’s time tostop explaining some complex facet of JRuby and instead just fix JRuby to removethat complexity.Nick—The Conversationalist 4
  5. 5. How 5 Authors He leads you through the text, and connects ideas back to previous concepts.He checks in to make sure you’re still with us. He challenges you with questionsabout what you’ve read. It makes for a smooth, engaging flow. This kind of writer isinvaluable for noticing what’s missing, anticipating what the reader will ask, andfilling in gaps.Ian—The Yak Shaver I’d love to write that half chapter on the compiler. But first, I’ll need to come upwith some examples—which I’ll try to compile. It won’t work quite right, becauseI’ve stumbled onto an edge case that isn’t implemented yet. I’ll dive into the JRubysource and create a patch… and so on. When you have one of these on your team,sic ‘em on all those miscellaneous tasks that you don’t want to fall through thefloor: wrangling the schedule, poring over the results of copy edits, etc. Now that you have a feel for the people behind this project, let’s talk about howit all happened.The Startup Curve It makes sense to tell this story chronologically. You get to experience the projecttrajectory with us in some sense, for better or worse. I’d like to refer to an imagethat really captures the feel of this trajectory. 5
  6. 6. How 5 Authors This is the famous “Startup Curve” that stood on a whiteboard at Y Combinatorfor a few years. Paul Graham drew it, and Trevor Blackwell added the whimsicalannotations. People have reposted it and reacted to it over the years because itcaptures so heartbreakingly the arc of starting a company—or at least perceptionsof starting a company. Here’s a little more legible version: 6
  7. 7. How 5 Authors The Process Upside of Buyer Acquisition Wearing Off of Liquidity TechCrunch of Novelty of Initiation Wiggles of False Hope The Promised Trough of Land! Sorrow Releases Crash of of Improvement Ineptitude I stumbled across this graph near the end of our project. It was a punch in thegut. Here was something that captured, immediately and viscerally, the heartburnand triumph of a big endeavor. If we imagine the Y axis to be something like moraleor velocity or mojo (instead of web traffic) and rejigger the labels a bit, we getsomething like this: 7
  8. 8. How 5 Authors The Process Release! Conservation Harshness of Momentum Euphoria of Reality of Kickoff Wiggles of False Hope Establishment Trough of of Rhythm Sorrow Nagging of Stakeholders Abandonment? This is such a descriptive arc for our project that I’m going to refer to itthroughout this talk. 8
  9. 9. How 5 AuthorsHow It All BeganLet’s start off with the story of how it all began. Harshness Euphoria of Reality of Kickoff In 2007 or so, the JRuby project was gaining enough momentum andpopularity that it was time to ask, “Shouldn’t the core team write an official bookon the subject?” They decided the time was right, and began (I’m waving my handshere) planning and outlining. This was before I joined the project, so the historyhere is vague by necessity. Ola and I had met previously at FOSCON (the predecessor to Open SourceBridge!), and he was kind enough to do a technical review of one of my otherprojects a few months later. That’s probably how my name came up when theywere looking for a co-conspirator on this book. In any case, the five of us sat downtogether for the first time during RailsConf in June 2008, at the awesome Doug Firlounge. The goal: figure out what this thing was that we’d be making. 9
  10. 10. How 5 AuthorsThe Definitive Book The team wanted to write the definitive JRuby book. What does that mean? Is itan exhaustive reference? A tutorial? Does it cover the internals? Who’s it for—Javapeople or Ruby people? One approach to writing a definitive work is to be exhaustive—to cover everyfacet of the project. Indeed, an early draft of the table of contents explored thatapproach: I. Introduction 1. Introduction II. JRuby and Java 2. Ruby 101 3. Java from Ruby 4. Ruby from Java III. JRuby and its Environment 5. Standard Libraries/Yaml 6. Configuring / Running JRuby and components 7. Inside JRuby a. JRuby architecture overview b. The JRuby Interpreter c. The JRuby Compiler d. Java Integration e. The JRuby API f. Extending JRuby IV. Working with Data 8. JRuby and JDBC 9. Working with XML a. REXML / JREXML 10. Web Services / SOAP a. RSS / Atom b. XML Builders V. JRuby and Rails 11. Rails Overview / Brief Tutorial 12. Rails and JDBC 13. Deploying JRuby on Rails VI. Testing in JRuby 14. Junit, Test::Unit, Mocking / Stubbing 10
  11. 11. How 5 Authors 15. Using RSpec 16. Benchmarking, Debugging VII. Other topics 17. JRuby and Security a. JRuby Security Overview b. OpenSSL c. JavaSand 18. Working with Application Servers and Frameworks 19. Creating Swing applications 20. Tools There’s nothing wrong with this outline in the absolute sense; it would havemade for a perfectly fine book—just not the book we were going to be able towrite. What forced us to narrow the scope was that all five of us were supremelybusy with our day jobs. The scope of the book was the major source of discussion at our dinner tablethat evening. I still have the notes I took as Charlie and the gang answered my n00bquestions like, “Who’s this book for?” “What kind of book do they need?” 11
  12. 12. How 5 AuthorsHere’s a cleaner version of the first page: 12
  13. 13. How 5 Authors… and the second: 13
  14. 14. How 5 Authors Here’s what that looks like when we condense it to an outline:I. JRuby ⁃ Basics / Installation ⁃ Java from Ruby ⁃ Ruby from Java ⁃ CompilerII. Libraries ⁃ Rails ⁃ Hibernate ⁃ Rake ⁃ Swing ⁃ JMX ⁃ JMSIII. Appendices ⁃ Ruby 101 ⁃ Contributing 14
  15. 15. How 5 Authors Here’s what the finished book looks like (minus a couple of obvious things likethe bibliography): I. JRuby ⁃ Basics / Installation ⁃ Java from Ruby ⁃ Ruby from Java ⁃ Compiler II. Libraries ⁃ Rails ⁃ Hibernate + Databases ⁃ Rake + Deployment ⁃ Testing ⁃ Swing III. Reference ⁃ Ruby 101 ⁃ Configuration ⁃ C Code ⁃ JMX + Sysadmins It’s amazing what having a simple rallying cry did for morale. With a clear ideain our heads, we were ready to get to work.Work vs. “Work” The original discussion wasn’t just about chapter ideas. We also decided on afew tools, based on how we expected to work together. This should have been ayellow flag: “how we expected to work together.” This was the first time thisparticular group of five had taken on a project—how on Earth could we have beenable to predict what exactly collaboration would look like for us? Not surprisingly,not everything on this list stayed in our toolbox for the duration of the project. The conversation went something like this: “What communication medium doyou use the most?” “IRC, probably.” “Okay, let’s set up a channel just for us.” “I cando that.” “What about logging and searching? If someone makes an offhand remarkthat turns out to be important, it’d be nice to be able to remember and find it later.”“Yeah, I can set up a bot for that.” “What about large files?” “How about Google 15
  16. 16. How 5 AuthorsGroups?” “Yeah, we should have one of those. I’ll set it up.” And so on. Has anyone ever seen or been part of an open source project that’s gone likethis? “My project is: I’m going to write a brand new operating system. Step 1:register a GitHub project. Step 2: get a Lighthouse account for bug tracking. Step 3:set up the wiki. Step 4: create a mailing list….” All of these things feel like work, but none of them are work! The lesson here isknow what you need your tools for before you choose your tools. Otherwise…well, I’ll tell you.Tools, and How to Throw Them Away Over the two-year course of this effort, we tried a lot of different technologiesfor collaborating. Some of them served us well from beginning to end. Others gotset up and then abandoned. (That’s not necessarily a bad thing. An experiment thatproves a result you didn’t expect is still a successful experiment.) Still other toolsdidn’t really prove useful until we changed how we were using them. Here are a few of the things we tried in the beginning.IRC IRC has been a great medium for the JRuby core team to answer coders’questions. Since everyone was so comfortable in IRC, and since it was a placewhere the core authors were very likely to be at any given moment, we figured it’dbe a natural fit. There are some differences between using IRC as a help forum and using it as acoordination tool for writers, though. For one thing, with only five people using theroom there’s never a critical mass of voices to keep the conversation going. Foranother thing, we had troubles with logging and searchability—if someone saidsomething crucial in the heat of discussion a month ago, anyone who didn’thappen to be in the room out of time was out of luck. It turned out that e-mail did a much better job at searchability and “what’d Imiss?” recovery. Sounds obvious in retrospect, doesn’t it? What can I say, we were 16
  17. 17. How 5 Authorsnew at this.Google Groups We had high hopes for big collaborative tools like Google Groups. We got thebright idea that we needed a place for stuff that was temporary (unlike source code)but needed a home (unlike e-mail). Think chapter/author assignments, audio files,etc. We had an initial flurry of migrating stuff here from e-mail attachments, andthen total neglect. We were just too small a group of people to get much use out ofthis. And as for chapter/author assignments? Reality was much more fluid than aspreadsheet could capture.Skype The hardest part about getting started with the book was deciding what we weregoing to write. The one guy with the most writing time (for the moment) was theone who knew the least about the subject matter. Fine for writing the introductionand a few chapters on specific technologies, but when an obscure question cameup on Java method overloading—we needed to talk. E-mail has slow turnaround time. With IRC, we’d have to compete with thedozens of people in the #jruby chat room next door who needed help right now.We hadn’t discovered iChat yet (no idea why). We figured out that Skype had theimmediacy we needed, and kept people focused on the current conversation. The initial plan was: 1. Have occasional lengthy Skype calls on demand. 2. Record them with Audio Hijack. 3. Post them to Amazon Web Services (they were too unwieldy for Google Groups). 4. Listen later to transcribe or just get answers during the writing process. The way it actually worked out was: 4. Never listen to the calls again, but find that talking helped us (momentarily) get unblocked. This fact went unnoticed at the time, but came in very handy later.Harshness of Reality 17
  18. 18. How 5 Authors Here’s where we are on the timeline at this point. After our first meeting at thebeginning of June, it took about a month and a half to get physical contracts mailedaround to everyone and signed, and get everyone commit access to the sourcerepository for the book. (As an aside, the Prags use a coder-friendly markuplanguage for their writing system—authors check their text and their code examplesinto the same repository.) So the work in earnest began in mid-July. During July and August, we toyed around with IRC. In September and October,we had those lengthy Skype calls and tried to figure out what to do with the result.Ola wrote the database chapter, and during a four-hour train ride to Seattle I wrotethe introduction. The pessimist would look at this process and say, “These guys are spinning theirwheels.” The optimist would say, “They’re just learning each other’s styles and howto work together.” I’ve thought one or the other or both of these things severaltimes. At any rate, at this part of the story the initial rush of enthusiasm has passed,and we’re entering the Trough of Sorrow. 18
  19. 19. How 5 AuthorsThe Trough of Sorrow As you’ll recall from the Startup Curve, the Trough of Sorrow is the long slog inthe middle of a big project when it’s difficult to see progress—either because thereisn’t any, or because the goal still feels so far away. Wiggles of False Hope Trough of Sorrow Nagging of Stakeholders Abandonment? The way that this feels can best be told through the conversations among theauthors, or between the authors and Jackie, our patient editor.Conversations One of the recurring themes throughout this endeavor has been the “what’sgoing on?” conversations.July Jackie (our editor): What’s happening with JRuby? 19
  20. 20. How 5 Authors Ian: Nothing. I have no authors. Couldn’t track anyone down.... Jackie: Can you try again this weekend? Don’t get discouraged justyet. Of course, that’s before we even had contracts or commit access, so not muchprogress was expected yet. Even so, it’s clear I hadn’t yet learned that, as they say atApple, “reasons stop mattering” when you’re supposed to be the one coordinatingthe project.August Jackie: Anything happening with JRuby? Ian: Good news from Sweden. Ola’s starting the chapter onHibernate.... Even in the dark times, we were still making progress. It was tough to rememberit sometimes. In the fall of 2008, Ola wrote two pretty hefty chapters, and I wrotematerial that ended up in the introduction and other places.September Jackie: BTW, if nothing is happening, we should talk about it soon. Ian: Ola just released a bunch of code... following up to see if he’sready to write about it.... I’ve just proposed a “bookfest” where... wesit and do nothing but write.... So, starting a chapter isn’t the same thing as writing a chapter. Even so, the stuffthat has to happen (code examples) is happening. It’s just not visible in the PDF yet. This is also the first time we talked about writing together in person, though itwould be the better part of a year before we actually did it.October Ola: It seems that the book will take a long time to get finished...,and I really want to get going.... Ian: Its just been difficult [for the team] to justify writing aboutJRuby when they could either be hacking JRuby or helping someone.... On 20
  21. 21. How 5 Authorsthe other hand, a phone call gives us a solid block of time with eachother, where we have (nearly) 100% of one anothers attention. If there were a theme to describe all of our difficulties—mine included—itwould be “divided attention.” We all had day jobs, and even aside from that, all ofthe core team members had JRuby to maintain and users to help. It’s so, so easy tosit down to write a paragraph on feature X, realize that feature X doesn’t yet dowhat you want it to, and dive into the code. The thing that helped a bit here was a phrase that kept coming up during ourinitial visit: “JRuby as it will be.” It’s okay to write about things that are coming inthe next version. Don’t stop the writing to add the feature (yet), we told oneanother. Just document it, and put a tag in the text that says, “Note: the followingtechnique won’t work until feature X makes it into the code (expected in v1.n).” We would later call this technique “Book-Driven Development.” November and December passed with the same trickle of progress. We spenttime shoving words around the page, but not enough time writing new ones. Then,in January, a new chapter landed!February Jackie: Is [Ola’s testing chapter] ready for me to review? .... Thislooks really good! A wiggle of hope! New material and improvements visible to the reader! Butfast-forward to April….April Jackie: How is it coming along? Ian: I feel a bit stalled..., and now things just seem... slow. Jackie: How can I help you get back on track? Are you gettingdiscouraged? This is the low point on the curve, the flirtation with abandonment. Normallyauthor teams are a little more together by now and don’t need the developmenteditor step in and to get people talking. 21
  22. 22. How 5 Authors The offer to help could be a motivational technique. Or it could just befrustration. In either case, Jackie’s been a great sport this whole time.Don’t Give Up Here’s the message I’d like to have sent back in time to my summer 2008 self.Don’t know that I’d have believed it, but it would have been worth a try. There are times in a multi-person project when you’re going to feel utterly,utterly alone. You’re going to log into Skype and no one’s going to be there. You’regoing to send out e-mails that don’t get a reply. Don’t give up, don’t despair, anddon’t give up. There’s an easy kind of reaction to have here: “I’m terrible at this, might as wellforget it.” This is kind of a perverse backward narcissism—focusing on the selfinstead of the project. What an easy cop-out; what a convenient excuse. Nobodywould blame a terrible writer for not writing. Acknowledge these feelings and push past them. At this point in the project,there was enough critical mass of text where I could do something. Even if it’s justanother editing pass through a chapter, or a new appendix, or something. As it turns out, there was something small and simple we could all do thatwould make all the difference to the project. 22
  23. 23. How 5 AuthorsEstablishment of Rhythm We’re now in the third and final phase of the startup curve: the establishment ofrhythm. I’m speaking both metaphorically in the sense of a group operatingharmoniously, and literally in the sense of finding a heartbeat for the project. Release! Conservation of Momentum Establishment of Rhythm Actually, “heartbeat” is quite a telling term if you think of its medicalimplications. With the patient going so long without a pulse, it’s no wonder weentertained thoughts of giving up and calling the coroner.A Personal Inflection Point For me, there was a personal inflection point in this curve in the summer of2009. JRuby saved my butt with a deployment at work. I’d always seen JRuby as thisneat alternative Ruby that you’d use if you needed Java interoperability. What I’dmissed was that JRuby was becoming a first-class Ruby implementation in its ownright. For certain uses (including my own), it could out-Ruby Ruby. At that point, JRuby became my preferred Ruby. Don’t get me wrong; like any 23
  24. 24. How 5 Authorsirredeemable tinkerer, I’ve got a stable of Ruby implementations sitting around onany given computer, and love them all. But JRuby became the one I reach for first. During this process, I started finding (and occasionally, fixing) bugs specific tothe older platforms I was using: Windows XP, Mac OS X Tiger, the PowerPCinstruction set, and so on. I started to be able to write with some limited authorityon the subjects I was meant to be covering. It makes a huge difference to go from “Iwill research this, and then write about it,” to “I remember this because I learned itthe hard way, and I can write about it now.” In addition to this turning point that was kind of personal for me, we enjoyed abig turnaround together as a team. There were three main components to thiswelcome change: finding the project heartbeat, working together in person, andkeeping the momentum going once we were apart again.The Project Heartbeat We made three little leaps forward in the summer of 2009, right after we got thebig wakeup call. The first thing we did was to establish a regular rhythm for theproject—a literal week-to-week rhythm. In June, we started using Pivotal Tracker to keep a backlog of our work. This is aweb-based project tracking tool that encourages your team to break remainingwork down into small pieces—writing a single section of the book or revising onechapter, for instance. In Tracker parlance, each piece is called a story, and wefound it helpful to phrase our stories as statements of fact. For example, rather than“Write section on Maven,” we might say, “Section on Maven describes Rakeintegration” or “Section on Maven incorporates editor feedback.” You don’t give time estimates in hours. Instead, you work in relative terms; e.g.,“this story is twice the size of that one.” (See McConnell on software estimation forevidence that people are much better at these kinds of estimates). You arrange thetasks in the order that they need to be done, and start working. After a few weeks,the software has an idea of when all your tasks are going to be done. 24
  25. 25. How 5 Authors It’s a good way to find out early in the project whether or not you’re going tomiss your deadline. We sure could have used this earlier on, because the onlydeadlines we were even remotely good at meeting were ones we planned with thistool. Before then, we’d say things like, “I dunno, the new chapter will probably beready in a month or so.” At least we were vague, but still—that kind of estimate waslaughable. Why should the publishers ever believe us after we went so long withoutmeeting any commitments? Because we finally showed evidence that we coulddeliver. There are a couple of ways to keep the information up to date in a tool like this.You can watch your project’s files for changes, talk to your teammates about whatthey’re working on, and update the data yourself. Or your collaborators can log inand update their own statuses individually. We used a little of each approach, andhonestly there wasn’t much difference. The hard part isn’t entering the data, it’sfiguring out what everyone’s supposed to be doing. Having each person’s commitments spelled out in one place that we actuallyused was a huge help for us. It made us look like we were really on top of things 25
  26. 26. How 5 Authorswhen our editor came to us a month or two after we’d been doing this and said,“How about delivering work in iterations?” Now, when she asked “how’s it going?”every couple of weeks, we had concrete answers, as well as plans for the nextweek. Not every week went according to plan, but this was still a huge stepforward. After we’d been tracking our work for a few weeks in this manner, it was timefor the next productivity boost: meeting in person.Writefest! We’d been loosely entertaining the idea of having a “writefest” for nearly a year.We never made any concrete plans until a few things came together in the summerof 2009. A few of us simultaneously found a little breathing room in our day jobs /conference schedules. We’d observed enough momentum in Pivotal Tracker that wefelt we’d have something concrete to accomplish together. On July 6, I flew to Minneapolis and spent a few days writing with Nick andCharlie at dining room tables, coffee shops, bars, and restaurants all over the TwinCities. Sometimes their families tagged along, and sometimes we soloed in quietisolation. But man, did we turn out text. At this stage, we needed to write using a tool that would let us all see what wewere working on. Google Docs fit the bill. It has simple formatting controls, so wedidn’t waste time fiddling. When one person makes a change, the rest see it just afew seconds later. 26
  27. 27. How 5 Authors In this screenshot, you can see echoes of our “JRuby as it will be” sentiment. Wewrote a few sections like these, where we didn’t quite realize what JRuby needed todo until we got ourselves into tangles expressing behavior that needed to besimplified. We wrote the bulk of the “Driving Java from Ruby” chapter one night over beersin a Minneapolis restaurant, jumping from concept to concept. That information isone of the first thing someone new to JRuby needs, and it’s really fitting that nearlyall of us had a hand in that chapter. Google Docs served us well for a few of the other collaborative parts of thebook. The chapters on embedding JRuby and on the compiler were each two-manjobs. The web browser was the place in our computers where a lot of us were“living,” and therefore the shortest path from “I have an idea” to “Wow, I’ve justwritten ten pages.” Once a chapter had stabilized, I’d save it as HTML and use a few macros in mytext editor to convert them to the markup language used by the publishing system. After the writefest was done, how could we preserve and protect thismomentum we had built up? By meeting regularly via conference call. 27
  28. 28. How 5 AuthorsRemote Standups As you’ll recall, we used Skype early on in the writing process. We’d record thecalls with the best of intentions, but we wouldn’t do much with those recordingsafterwards. It was time to look at what we thought we were getting out of voicechat vs. what we were really getting out of it. We had thought that Skype was going to be a tool for generating content.Record, transcribe, edit, release. It turns out that transcribing is a huge time sink,and we seldom did so. Not only that, but the act of having the call—not therecorded talking—was the thing that got us writing again. What Skype really was for us was a tool for maintaining the project rhythm. Thefirst Monday morning after the writefest, we established regular Monday/Wednesday/Friday morning conference calls. They were a little bit like the standupmeetings some agile software teams use. We’d talk about what tasks we could markas complete in Pivotal Tracker. We planned work. We talked about places where wewere stuck. We vented. The meetings became a habit, but not an obligation. We never felt compelled tomeet just for the purpose of going through the motions. And indeed, we did cancela few meetings when there was nothing new to say and it would have gotten in theway of working on the task at hand. But those cancellations stand out as rareexceptions. (I can still remember the feeling of being logged in all alone—but ourtime in the trough of sorrow taught me that these feelings are temporary.) Because we weren’t attached too much to form, we experimented a little withthe tools we used. If the Central Time Zone folks had to be somewhere loud, we’dmeet in iChat or Skype text chat instead of having a conference call. These onlyworked because we’d built up a history of talking to one another, and could nowsafely undertake the much more distraction-prone activity of text chat without toomuch risk of the conversation dying. We kept up the meetings up until June of 2010; that’s nearly a year of talkingregularly. It was seldom all five of us on one call, but most weeks everyone made itinto at least one call. We had a few remote meetings sporadically after that, butreally didn’t need them any more. The writing was nearly done, and now it wasdown to the million little tasks that get lumped in as “editing.” 28
  29. 29. How 5 AuthorsRelease! Four months after we pulled back from the brink of abandonment, we had builtup enough momentum to where we knew we were going to finish this thing. Sowith the publisher’s blessing, Charlie stood up in November 2009 at the first everJRubyConf and announced publicly that we were all writing the official JRuby booktogether. No backing out now! By March 2010, we had enough material to release a beta version of the bookas a PDF. This stage was crucial for us. Even though we ran all the code in the bookourselves on a regular basis (mostly with the help of automation, thank goodness!),our early readers still found a few examples we needed to tweak. More importantly, early readers identified concepts they wanted to see covered,and they did so at a time in the project where we still had time to do somethingabout it! For instance, in the database chapter, we added installation instructions forsome of the software our readers would require. In the testing chapter, we wereable to add a section on the Webrat testing tool. When the beta came out, the book was about half done. Every few weeks, we’drelease a new beta while we wrote new material. Finally, in August 2010, I sent thistweet: The final chapter is in our editors hands. The book is written.Tonight, Ill try this "sleep" thing Ive heard about. So at JRubyConf 2010, we could truthfully announce that the book was done,and would be going to press in December or January. In the meantime, we still hada couple months of editing to do: first with our development editor Jackie, thenwith our second round of tech reviewers, and then finally with the copy editor. It was a long march, but it was worth it all in January when we got those boxesin the mail and held those real books in our hands.Lessons Learned 29
  30. 30. How 5 Authors I’ve been scattering little asides throughout this talk to describe instances whenreality stood up and gave us a smack of the truth. Here are those nuggets of hard-earned knowledge, gathered into one place for convenience. Please keep in mindthat these won’t apply to every project or team, and indeed might not all apply ifthe five of us got together tomorrow and started a new project. It may look like a book, but it’s actually a software project. It may feel like writing, but it’s actually project management. Focus your efforts around a simple rallying cry (“Using Ruby from Java, UsingJava from Ruby”). Don’t choose your tools before you know what you need them for. It wasn’t somuch that using a specific tool caused us to suddenly make forward progress. Itwas more like we had finally created a way to work together, and we found thetools that were right for us at that time. An experiment that proves a result you didn’t expect is still a successfulexperiment. Self-doubt is a form of narcissism. Eat your own dog food. For me, progress really improved when I started usingJRuby all the time. Meet in person at least once. Have a project heartbeat. Form good habits, not empty obligations. You are not alone. It will feel like it sometimes, though. I hope you’ve come away with this talk informed about long-running,geographically widespread collaborative projects—or at least entertained by ourstruggles to complete one. Even more importantly, I hope you feel encouraged towrite about the technologies you’re building and bring your knowledge to newpeople. Because there’s one more lesson learned that I hope is really clear after allthis: If the five of us can write a book, you certainly can. 30
  31. 31. How 5 Authors31