From the monthly archives:

August 2009

Specify Story, not details

by Pearlbear on August 19, 2009

I’ve been a fan of user stories for several years now. User stories are a way to describe a set of functionalities of an application in a way that is focused on results – it’s easy to connect to mission. An example from an events management application:

The organization should be able to create several different kinds of events, and determine for each kind of event which detailed information will be taken. Those events can be displayed in a list or calendar format. Users can register for events, and pay using a credit card.

There are many ways to describe this story – it certainly can be a lot more detailed, but what’s clear is the result of this functionality. And, of course, user stories are great for agile development process.

Developers would determine how much this function would cost (based on our knowledge of the tools we use, and the time it takes using those tools to generate this sort of functionality), and clients would know exactly what they are getting from a functionality standpoint. When this functionality is complete, everyone is happy. The developers get reasonable compensation for a job well done, and the clients get the mission-based functionality they asked for.

And it would avoid a situation which I have become recently far too familiar with – vendors who underbid projects, and then feel the need to resort not to the intent of the contract, but the letter. Everyone knows it is utterly impossible to specify every detail in the letter of a contract – sometimes letter of the contract, unfortunately, details things like fields and queries, not functionality. The letter of a contract will be, almost by definition unless based on functionality, an inadequate representation of the final result needed. In this case, no one really wins. The clients either don’t get the functionality they expected, or they pay extra for it, and they leave the project with a bad taste in their mouth about the vendors, which will only come around to hurt the vendors later.

Tagged as: , ,

{ 4 comments }

Diversity and Open Source

by Pearlbear on August 1, 2009

The python community has started a conversation about diversity, with the ultimate goal of creating basically a welcoming statement. It comes out of Kirrily Robert’s keynote at OSCON about women and open source. There is a cool site from the Ruby community called Railsbridge, and one of their guidelines is to “Reach out to individuals and groups who are underrepresented in the community.”

There has been, of course, a lot said about the fact that although women make up 20% of the tech field, they only are approximately 1.5% of open source communities. There have been long standing groups that have tried to address this, and new efforts as well. Some open source communities are more diverse than others. In her keynote, Kirrily talks about two open source projects, Archive of Our Own and Dreamwidth that have a majority of women involved, which is rather unusual.

A short twitter conversation I had with a colleague brought up the issue of whether or not this is just an exercise – will this actually lead to any lasting change? That’s a good question.

Kirrily has a set of really good guidelines for open source communities:

  • Recruit diversity
  • Say it, mean it
  • Tools (Tools are easy)
  • Transparency
  • Don’t Stare
  • Value all contributions
  • Call people on their crap
  • Pay Attention

As a long time open source user and advocate, even though I am someone who rarely finds people like me in open source projects (i.e other women of color), I’ve always seen the open source movement a potential avenue for the greater involvement of people other than white, straight, young men, because theoretically (this is the important part) one’s involvement in a community is pure meritocracy. But so many open source communities have so far to go when it comes to being welcoming. I’m reminded of sitting in Drupalcon in DC and hearing Dries talk about the “beard length” of the developers. And of course there was the huge brou-ha-ha around a presentation at a recent Ruby conference.

And, of course, there are other factors as well. There are far too few places like The Community Software Lab of Lowell, MA, who’s mission is:

We write, administer and maintain open source software to serve the underserved.
We use and improve the skills of people with underused skills
We work to make hacker sub culture values (transparency, meritocracy and generosity) the values of the entire culture and bring about the post scarcity society.
We work toward our mission by trying to achieve our short term goals transparently and generously while accumulating only necessary wealth.

So what will it take? Will this effort in the python community pan out? I think it’s a great start. I think the first step is definitely a focus on community environment. Is it friendly? Is it welcoming? Is it easy for new developers to start, and get deeper in? Are there good mentoring models? All of that makes a huge difference. And having a statement doesn’t at all guarantee anything, but it provides something people can point to and say “this is our goal.” Better than nothing, and a lot better than many open source communities are doing.

{ 12 comments }