Q4 - Alistair Cockburn - The Books

Q4 - Tell us about your books.  Which order should I read them in and what would I get out of each of them?  Which one are you most proud of?

Well, there's something like 8 books (depending on what the definition of 'is' is, and 'book' and 'your'). Here are some unpublished notes about them ...

Surviving Object-Oriented Projects was a summary of my investigations and project debriefings in the early 1990s. It contains snapshots of the projects I debriefed that led me to to recommend the kinds of things I do. Very little of it is specific to object technology, most of it is about what makes projects succeed and fail, how to staff for experimental versus production projects, project management strategies, and of course, how object oriented programming affects things. I still meet people today who tell me this is their favorite book of mine.

I succeeded quite well with it, with one exception. I wrote an appendix at the back called "Project Management Patterns". One of the reviewers (in 1996) complained bitterly about me getting on "the patterns bandwagon" and suggested strongly I drop the term "pattern".

Seeing that "pattern" is synonymous with "strategy", I did a global search-and-replace of "pattern" to "strategy" (and "patterns" to "strategies"). The surprise was that there were literally no further editing changes to clean up the wording change! When I submitted the appendix to PLOP 96, I changed the words back to "patterns", and after incorporating their recommendations, changed them back to "strategies." Try it – you'll find that most patterns are nothing more than strategies!

However, it turned out that my reviewer was completely wrong! and I was a fool to listen to him. Had I stuck with the word "patterns", I could have kicked off a project-management patterns movement, whereas as it now stands, few people have any idea that there are a dozen project management strategies sitting in the back of that book. Foo.

Nonetheless, I got permission from my wife to put all the proceeds from the book into a separate savings account for a little sports car. In 1999 I had $20,000 in the account, so I went to the local Mazda rep, showed her my screen saver image of a silver Miata, told her I had exactly $20,000 in the bank from my royalties, and lo and behold! She turned up with a silver 1999 Miata that, after taxes and registration came to $19,986. My son and I picked it up and bought ourselves (a small) dinner on the way home with the remains of the saving account.

– Note on creating a macro-structure –

I spent weeks drawing pie charts and mind maps of topics to make sure that it contained the full range of topics without getting stuck in any job speciality. I'm not really a mind-map person, but I tried it. What worked for me in the end was a three-layer pie chart, the inner pie showing % of space allocated for the major topics (chapters), surrounding circle showing % of space for major headings, some third-level breakdowns in a third surrounding circle. From these percentages I could calculate how many pages to spend on each topic (I knew I wanted a 300-page book, so I just did the math, then wrote that many pages on each topic.)

I can recommend this as one way to structure your book. Keeps it to size (and I know _many_ authors who could benefit from this discipline).

– Note on writing style –

I used to write really complicated sentences (still do, given half the chance). I ran across the book Revising Business Prose, a short, small easy-to-read, 80-page paperback, which taught me to write short, active sentences. I took one entire pass through the book splitting compound sentences, choosing shorter words and eliminating adjectives and adverbs. The book was much the better for the change. Try the book, I believe you'll like it. (p.s. I only used the advice in the first half of the book.)

– Book 2 –

Crystal Clear was the second book that I wrote (1999). However, XP was just on it's ascendancy at that time. I decided I couldn't compete with it's popularity, so I stuck the book draft on my web site and let it sit for five years, until friends pestered me to get it published just so some people would see that there is an alternative to XP.

Amazingly, a professor Chris Jones, then at Weber State University in Utah, found the draft on my web site, downloaded it and made his students use it for their semester projects - And he never even wrote to me! I found out years later when talking with his son Nate during an agile roundtable. Chris Jones later used my brand-new undergraduate software engineering text – while I was writing it, in real time! Talk about someone willing to experiment.

– Book 3 –

At that point I signed a contract to write a book series! Which meant I needed to write the zeroth book in the series, the anchor book. This was originally entitled Software Development as a Cooperative Game. I started drafting it in 1999.

– Book 4 –

But while I was drafting that, I was being deluged with catastrophic book proposals about use cases. I decided if I wasn't careful, I'd find myself having to teach out of them. Out of desperation, I scraped my hard drive for whatever I had on use cases and overnight submitted a 100-page book proposal for Writing Effective Use Cases. That was put on the front burner and came out late in 2000 – and has been paying my mortgage ever since.

– Note on macro-structure –

I'm famous for not finishing books. I generally run out of energy by half-way through the book (as, for example, Revising Business Prose, which is really short, but I still only read half of).

So for each of my books, I've worked hard to arrange that all the really important stuff happens in the first half of the book, preferably before page 100. The hard part, of course, is what to fill the second half with. I toyed with rubbish generators, but concluded that some readers would actually read the back half of the book and complain. So I fill the second half of the book with helpful-but-not-critical information. Dedicated readers can then mine the back half for extra goodies.

– Book 3, again –

I got back to The Cooperative Game, whose writing was redirected by the writing of the Agile Manifesto. The publishers renamed it Agile Software Development, even though the book is much more general than just agile.

What was fun about this book was that I got to design the page size, 2-column layout, typography, and even ran its production. We had a tight deadline to get it out by OOPSLA 2001, so I used all the advice in the book in doing the copyediting, illustrations, layout, etc. We shrank the time-to-production from 5 months to 5 weeks!

For example, at one point the copyeditor was resisting meeting me for a discussion. I started to explain why it would be useful to meet. She said, "I know all that – I'm editing that chapter!" :-)

The first edition of Agile Software Development was and still is my favorite book, because of the Introduction and first two chapters. It was the book I had long wanted permission to write, because in it I got to talk about the nature of communication and humans. Without the first two books behind me, I'm not sure I would have felt brave enough to write it.

– Note on macro-structure –

I had trouble getting the macro-structure of this book. The pie charts didn't work. What solved it was Writing For Story. Where Revising Business Prose teaches how to edit single sentences, this book teaches how to construct the macro-structure. Using it, I constructed the Agile book as a sort of mystery story, where every chapter resolves certain tensions but introduces new tensions to resolve. Take a look at Writing For Story and see.

I failed on my strategy of making the second half of the book "goodies", although I did get the most important information in before page 100 (my publisher wrote me just as the book was gong to press, "I'm just readng the book now – I'm up to page 80, and you still haven't gotten to the meat!" I wrote back – "That IS the meat!").

So this book is really two books in one – the first halves of two books, glued together.

– Book 5 –

All this time, Steve Adolph, Paul Bramble, Andy Pols and I had been trying to write a patterns version of Writing Effective Use Cases. I was also working on my doctoral thesis at the University of Oslo.

It was all too much, and I withdrew from the Patterns for Effective Use Cases after we worked out the pattern language. Steve and Paul invited my back onto the author list just before publication, but I thought that would take too much attention away from the work they had done, so Andy and I put ourselves as "contributors".

– Book 6 –

My doctoral thesis, which I completed late in 2002, was entitled People and Methodologies in Software Development. It was intended as the academic version of Agile Software Development, just as readable, but with the necessary attention to research method and full of researh citations. I gave my Agile book to the examining professors, and my thesis to Addison-Wesley. AW never got around to publishing it :-(.

Part of the point of writing the thesis was to let people who had read Surviving OO Projects and who had heard me rumble on for years about my project debriefings, get a closer look at what those debriefings and interviews looked like. It was also to answer the question, "Can methodologies ever converge?" (The answer is No, we'll need an ever-increasing number of them, which means they should be really really easy to construct).

– Note on macro-structure –

I rewrote this thing 3, 4, or 5 times. What cracked the problem was Lars Mathiassen cornering me and saying – "A thesis should answer three questions. You know those answers, don't you?" I said, "Yes." He said, "What are the three questions those answers answer?" I told him. He said, "Good – Start by saying what the three questions are, then answer them."

Egad! So easy! (after the fact). That's exactly what I did, and I still like the structure of the book: No windup, it just starts running at full speed. I wish more dissertations did that.

– Book not! –

My next book was supposed to be the project management patterns book, but the Agile Development Conference got in the way – I spent two years creating and babysitting that before the AgileAlliance took it over, and by that time I was already past the PM patterns topic – the book had "written itself" in my mind and my body didn't want me to take the time to write it onto paper. Shucks. I really miss that book.

– Book 2, finally! –

Finally it was time to dust off the Crystal Clear book and blow the cobwebs out of the words. It had been intended back in 1999 for people who didn't have any notion about small-team, incremental-iterative development. What a change in the intervening five years! By 2004, thanks to XP and agile, those topics didn't need any defending.

Crystal Clear: A Human-Powered Methodology for Small Team is currently my second-favorite book, because it covers pretty much the full set of topics needed by a team, with concrete examples of each artifact needed.

While writing it I discovered that project properties are much more powerful than methodology rules. Instead of saying, "Follow these rules, and good things will show up," I found it stronger to say, "Here are some good things to have show up – Ensure that they do!" And then let the people on the team find ways to get them to show up.

– Book 7 = Book 3, revised –

By 2006 it was time to update Agile Software Development, because five years had passed since the writing of the agile manifesto, and there were five years of discussion and misunderstanding to deal with.

After this revision, Agile Software Development: The Cooperative Game had become three books –  a 100-page book about people, a 100-page book about methodologies, and a 100-page book about agile development. If you read it, you might like to approach it in this way.

– Book 8, unpublished –

In fall 2006 I started on my next book, tentatively titled Software Engineering in the 21st Century, an undergraduate textbook for third-year undergraduates in a semester-long course. Neil Harrison and Chris Jones agreed to teach it in two separate courses while I wrote it in real time underneath them! Brave or foolish, we did it that fall term. I turned in 20 pages of book, powerpoint lecture slides, homeworks and class activities, twice each week, Monday and Wednesday. That was a wild ride (and it took me months to recover from the exertion, because I was consulting, teaching and traveling at the same time).

That book isn't out in paper form, because I don't have a publisher. I may publish it in pieces on my new web site.

I like this book, because I got to incorporate everything I knew and a bunch of stuff I didn't, all the latest and greatest ideas I could find about modern software development, cut down to the size suited for undergraduated. You can read about this book and course on my web site.

That leaves me with two books outstanding (PM strategies and the undergraduate SE book) plus a zillion more trying to get out. I'm literally limited by typing speed.

Which do I like best? Still the first edition of Agile Software Development. It's thinner than the second edition (I like the heft of the thinner book), and it contains that Introduction I enjoyed writing so much.

Which should you read first? Dunno – what's your reading style? Some people like Crystal Clear because it's the most concrete, some like Agile Software Development because it's the most theoretical. Some like Surviving OO Projects because it's contains the most project pragmatics. These three actually form a sort of trilogy, and I wish they could be bought as such.

Only read Writing Effective Use Cases or Patterns for Effective Use Cases if you're in the use case business, because they are really sharply focused to that specific topic.

Read People and Methodologies from my website if you're curious about my project debriefings or the argument that methodologies are transient and should be picked up, used and thrown away like tissues.

Go and get lost in the (currently) 800 content pages on my web site if you want more of anything. http://Alistair.Cockburn.us.

Comments

[Nancy]

Hi,

Excellent article - I really appreciate your knowledge about Agile Software development and etc, I have bookmarked it for later viewing and forwarded it on.

Cheers.