Tag Archives: software developers

Power, dissent, and bullying in software developer communities

Posted on by

Grassroots developer communities form around shared values in dissent against institutions and norms that dehumanize their work and diminish their efforts. They attack these orthodoxies with humor, heretical thinking, and hard work.

This benefits society when developers defy those with greater power. It harms society when developers bully people with less power.

At the ThoughtWorks sponsored Agile East, Martin Fowler spoke to his post, SmutOnRails.

Part of the community was offended by a presentation at the GoGaRuCo (Golden Gate Ruby Conference). Others fought back saying that no offense was meant, the presenter apologized, and that the tone was in the spirit of the Rails community.

(T)he view of the rails leadership seems to be this: that the objections to the presentation are yet another attempt to foist empty corporate values on the thriving Rails ecosystem… (more)

This debate is not unique to the Rails community. It reminds me of concerns my friend, Luke Melia, raised over jokes and behavior at the first Austin Alt.NET. Martin Fowler links off to a similar controversy in the Flash community.

It is also not unique to developer communities but developers in particular need to be concerned about the outcome.

Women, African Americans and Hispanics are under-represented in IT and even more so in software development. In 2001-2002 74.4% of software developers were men. 78% of those men were white.

In 1986 the percentage of women in CS programs peaked at 37%. The percentage of women in computer science programs has gone down since then.

In 2001-2, only 28 percent of all undergraduate degrees in computer science went to women. By 2004-5, the number had declined to only 22 percent. — What Has Driven Women Out of Computer Science?, NY Times

There were 15,000 women in CS progreams in 1986. Riding natural cycles this number was not matched again until 2003. This latter number contains a higher percentage of non-resident aliens who will not necessarily contribute to the US workforce.

This despite higher percentages and numbers of women acquiring college educations than men. In 2007, 33% of women 25-29 held a four year degree or higher versus 26% of men. 55% of graduates with four year degrees or higher aged 25-29 were women.

Women are even receiving the majority of degrees in science and technology. They have shown steady progress in biology, chemistry, physics, mathematics and engineering.

Metrics can be misinterpreted but these quantitative measures support a stunningly obvious anecdotal observation. US software developers are a white male enclave.

This is a power imbalance and we developers are part of the problem.

Isolation is a key factor for a higher attrition rate among women and minorities, said Teresa Dahlberg, director of the Diversity in Information Technology Institute at UNC Charlotte. People tend to associate with “like communities,” where people have similar backgrounds and interests, she explained. — Computer science lacks women, minorities, SD Times

So when we behave in a way that marginalizes and intimidates talented women and minorities, we abuse power. We become bullies. We are oppressors.

“There is a good amount of research that shows that women are judged more harshly than men, for hiring, evaluations and promotions,” she added. “Virginia Valian [author of “Why So Slow? The Advancement of Women”] shows this for women in science, technology, engineering and math faculty jobs.” Virginia Valian is a professor at Hunter College. — SD Times

Part of the problem may be a perception that software development doesn’t contribute enough to society. To the degree this perception is true it is damning. To the degree it is just a perception we have work to do as advocates.

Our actions need to be judged not by our intentions but by the outcome.

Requisite variety within our teams remains an essential enabling condition for sustained innovation.

Access to technology is growing across all tiers of class, race and gender both in the US and overseas. Diverse teams can better address our market and build software better adapted to our end users.

A more diverse workforce provides the kind of social change that will help us create a more humane workplace for developers.

Finally, anything that limits the number of able US software developers hurts our ability to compete.

When developer communities marginalize women and minorities, we conspire to isolate ourselves from the larger society. We defeat our own attempts to change the power structures around us and improve our lot and our output.

Agile 2008

Posted on by

toronto_skyline
Steven Doc List and I held a 20 minute presentation and 60 minute open space on software ethics.

I think the format works. Software ethics is not rules or reason, it is navigating essential complexity in building software and in moral choice. Descriptions that “abstract away its complexity often abstract away its essence” (Fred Brooks)

We embrace essential complexity using the values and practices of agile software development.

We can become better software developers using the same tools we use to build better software.

We can learn through practice to recognize and accept responsibility for the intended benefit and unintended harm we create.

We can retrospect on our actions and their consequences, engage in a conversation with our peers, learn from, challenge, and support each other.

Collaboration and Product Ownership

Posted on by

I’m presenting a paper, Great Scrums Need Great Product Owners, at the Hawaii International Conference on System Sciences.

The presentation is part of the Agile mini-track co-chaired by Jeff Sutherland and Hubert Smits. I co-authored the paper with the senior member of my product team, Ilio Krumins-Beens.

We survey literature to describe pragmatic and collegial relationships which satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. These limited forms of collaboration are common not just in our industry but within agile projects.

A common interpretation of the call for a single Product Owner is that the development team itself should play little part in shaping the vision and value priorities of a product backlog, focusing instead on efficient delivery of those priorities.

One of our major sources are the What’s Worth Fighting for series by Andy Hargreaves and Michael Fullan on collaboration in education.

The disempowering climate faced by teachers is a direct parallel to that faced by software developers disengaged from the business vision and value priorities of their work.

“… [W]e have collectively 45 years of teaching experience and nobody has ever asked us our opinion about anything where it would actually be put into action. And yet I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them. And I think that is very frustrating… I think I could help bring a lot to it and nobody ever asks, no one ever asks what we think. They just go ahead and proclaim and we have to follow.”

Its tragic how talented, experienced people are not allowed to bring their full selves to their work.

We contrast this with unbounded collaboration between a product owner and team. In unbounded collaboration an individual’s contribution is not constrained by their role or status.

It is a collaboration built upon high-performance, mutual respect and deep trust. The product owner walks a tight rope, engaging the team in an evolving product and business plan while guiding the project toward her vision and high-level goals. The team is passionate about the product they are building and feel personally accountable to the product’s success.

We argue that this kind of collaboration is at the heart of agile values and is a characteristic of the knowledge-creating companies upon which lean principles are based.

I’ll write more about unbounded collaboration, it’s opposites, practices we’ve used and what we’ve learned.

Scrum Gathering – Agile and Ethics

Posted on by

I’ll be presenting two talks at the November Scrum Gathering.

One of them is dear to my heart. I’ll be using this blog over the next few months to work up my ideas and document conversations I have around this topic.

The Ethics of Scrum and Agile Software Development.

Here’s what I proposed:

Presentation Description

Are Scrum and XP inherently ethical?

In the face of contradictory beliefs over what we do and how we do it, we software developers, agile or not, experience pressure to compromise our work and our due care for others. Meanwhile, as our products become more beneficial, more pervasive and inter-connected our potential to harm grows.

Attempts by the ACM and IEEE to engage us in a dialog on norms of conduct has resulted in a controversial code of ethics that borrows heavily from established engineering disciplines – mandating specifications to ensure effective software.

We, agile software developers are making an under-appreciated contribution to ethical practice in our field.

Whether our work is a profession or craft, we need to engage the larger community in a conversation about how our day to day actions affect our employers, our peers, and our society. This presentation will attempt to frame professional ethics in the context of agile values and practices.

Why is this topic of interest to Scrum Gathering attendees?

The discussion over norms of ethical conduct happens outside the earshot of most working developers. The day to day experience of Scrum practitioners is at a distance from those who concern themselves with software ethics.

As a Scrum community, we have a responsibility to help shape the expectations placed upon us by others. We cannot delegate our integrity. Nor can we defer concerns over negligence, recklessness, or intent to harm the human beings who use the systems we create. We openly discuss our projects, our working conditions, and our advancement but to protect those very interests we often deal with issues of conscience privately.

Yet the passion behind Scrum is, in part, an idealistic one – a hope that by dealing openly and responsively with our stakeholders we will build something of real value. We need to harness this idealism to encourage each other make better decisions in the interests of stakeholders who do not pay us and do not always have a seat at the project table.

Given the downstream effect ethical lapses large and small have on society, we need to engage in this discussion or have the wrong solutions imposed upon us by employers, institutions, and regulatory agencies.

Presentation Objectives

  1. Is it important for us to establish a shared commitment to ethical conduct?
  2. What obligations a software developer should feel beyond fulfilling the requirements of their employer?
  3. How the Agile Manifesto and Scrum/XP practices suggest a partial set of norms of ethical conduct.
  4. How agile organizations have started to provide their own statements of principles to extend agile values and encompass conduct towards our peers and society.

The Beauty of Team

Posted on by

Our team just beta-released our first consumer product. Along the way, they accomplished something of more strategic value. They matured into a performing, self-directed team.

The Team Ript Page

A decent manager encourages software developers to do their best work while allowing them full personal lives. The heart of this effort is fostering strong teams. Individuals have bad days, make mistakes, lose momentum. A team watches each other’s backs, challenges each other, teaches each other. They build upon each other’s creativity.

The beauty part for a manager is — if you create the right conditions, start with the right people, trust them and hold them accountable — the team does the hard work of becoming. They deserve full credit for their achievements including the most ambitious achievement which is themselves.

That doesn’t mean it’s easy. Getting this consumer product to the general public has taken fifteen months. From our first study of agile principles to our current practice has taken the better part of four years of continuous improvement.