Dreaming in Code and Community Source

August 19, 2007

Last week the UC Berkeley Kuali Student Project Community Council had a fortunate visit and presentation from Scott Rosenberg, the author of the book Dreaming in Code. I read this insightful book last Spring and immediately wanted to recommend it to twenty other people involved in community source and/or software development, thus I was thrilled that my colleague Bill Allison was able to bring Scott in to talk with us.

Dreaming in Code is not only about the Chandler Project, Mitch Kapor’s open source effort, but also provides a valuable history lesson in the software development holy grail for the perfect release — on time, on budget, and in-scope. The book is also a page turner.

One of the many tenets reflected within the book and in Rosenberg’s presentation, “Software is hard” (heard repeatedly from the mouth of Mitch Kapor in the book, but I believe Rosenberg says it originated from Donald Knuth, a Stanford Prof. and author of the tome, The Art of Computer Programming.) deserves some reflection. It is a statement that to many people is probably a no-duh statement. But to me, I think, “Thank God someone said that out loud!” However, most of the modern world doesn’t act like they believe that statement. In fact, programmers themselves often downplay the effort, using the term, “trivial” to describe what it will take to make some programming feature or bug fix. What I have seen over the years is that what “can” be done, and what “will” be done are often very different.

Scott talked not only about some of the general software history lessons and the lessons from Chandler, but also reflected on some of the lessons we are all learning from the web 2.0 world and agile development method. Some of the principles that jump out as immediately applicable to the Kuali Student and other community source efforts:

  1. Thinking about keeping projects small and simple rather than large and complex. (Yes, sometimes the way we frame it to ourselves matters!)
    It is easy to get buried in the “bigness” of a community source effort. There are many layers to manage: the external development partnership, the various requirements from all the stakeholders off and on campus, the local budget constraints, the balance of features and design with architecture, etc. The complexity of community source is matched, or perhaps even overwhelmed, by enterprise thinking. This is where SOA may come in handy.
  2. Producing software in small, short iterative cycles gets you somewhere.
    This is a lesson from Agile that higher ed can learn from. It matches nicely with an SOA model, but it also comes with its challenges such as how to integrate with user-centered design. The Sakai project, while not utilizing Agile, did work well in the way that it a) built on existing code, meaning something was in front of users earlier rather than later (some will say that this was its key problem — both perspectives are right!), and b) provided a platform so that many participants could deliver independently of each other. This had and continues to have its downsides. It is a challenge to usability, and difficult to create a solid feature roadmap, but it makes it easier to develop a key contributor-base and to develop buy-in from the end-user and local constituency that has been WAITING for this widget forever (tap, tap, tap). Questions from Rosenberg’s audience made it clear that some Student Systems stakeholders are anxious about this. The UCB team will need to address it in some way (not necessarily solve it).
  3. Planning, design, and testing should be at least half the project timeline…
    Deciding what to build (if you want “it” to be successful) is more difficult than building it. It has to a) meet someone’s needs and help them achieve their goals with minimal interference, b) work! This principle is often lost in the haste to achieve #2.
  4. Transparency and governance structure are your friends.
    Open source and higher ed public institutions have the concepts of sharing, transparency, and doing things for the greater good in common. Where successful open source tends to do better than higher ed (surprise) is in the governance of their development projects. Transparency is key here, but also knowing who is responsible for what and giving them the authority, based on meritocracy, to deliver. This means that not everyone is at the table all the time. Grit your teeth now, cause this means even you. And that should be OK, as long as you know why, who is at the table, and what you need to do in order to be at the table if that is so important to you.

Now back to Kuali student. The reason Scott’s book and talk are so interesting to me in this context is that the Kuali Student project screams, “BIG,” it screams “ENTERPRISE IMPACT,” and there are tons of local stakeholders tapping their fingers and clutching their scroll of requirements (in fact I am one of them!) which should deliver them a seat at the table.

There is no way the project can be successful without finding ways to manage, mitigate, and communicate its way through these factors.

Recognizing this, it is going to take a team of dedicated, focussed, disciplined, and open folks run this thing. AND it is going to take a lot of support, idea-sharing, and patience from those of us on the periphery.

Go Kuali Student! Go UC Berkeley Kuali and 2012 teams! I am rooting for ya.


3 Responses to “Dreaming in Code and Community Source”

  1. Wytze Koopal Says:

    Great post, Mara! Thx for your transparancy 🙂
    We can learn from all four principles. Especially #3 and #4 do ring some bells.

  2. John (Barry) Walsh Says:

    Mara, I also really enjoyed Scott’s book and found myself doing a mental checkup on the existing community source initiatives with which I am affiliated…Sakai and Kuali.
    It’s pretty hard to keep a student system or financial system ‘small’. The required functionality is what it is. But the second point about using iterative processes to produce discrete pieces of functionality is where I believe we can address the ‘big’ problem in some CS initiatives. The Kuali Financial and Research initiatives are driven by ‘the Reality Triangle’ of scope, time and resources and are constantly focused on the discrete deliverables that will be produced in the next three months. They actually meet f2f every three months at some location to take stock, re-adjust priorities and refocus on the deliverables. While these are expensive meetings, the community feels they are among the most worthwhile. It provides the personal contact and also the key element of transparency. The simple rule is that you must speak up at these meetings or forever hold your peace!!! No passive /aggressive behavior of silence followed by carping. The communities have become quite sophisticated in addressing this issue and the meetings are usually very lively but focused.
    I expect KS will find its own balance and process as they evolve.

    With respect to another of the above points ‘Planning, design, and testing should be at least half the project timeline…’, I could not agree more. The functional scope people drive these Kuali initiatives, not the developers. For their part, the project manager people set aside a full three months of QA work at the end of any intermediate release of code. During that period, just about every developer is engaged in QA, along with an army of subject matter experts to do functional testing.
    I believe your point about CS governance is a very insightful one, not generally understood in the broader ‘open source’ community. One of my colleagues suggests that CS is the coffee-shop or bar between the Cathedral and the Bazaar!!

  3. marahancock Says:

    Hi Barry — Thanks for contributing! You all at Indiana Univ. seem to have a really solid balance between local and CS effort and (at least to the outsider) have managed to engage your constituents (faculty, staff, students?) in the mission and value of CS. Can you provide any additional insight into how you’ve built that culture around these efforts?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: