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.

Posted: November 15th, 2009 under development.
Comments: none

After eight years with the same company, I spent the last sixteen months with several.

For those of you interested in Agile software development in NY I can tell you first hand that there is work.

The best opportunities exist for people who can demonstrate they get it — not just the practices but the values behind the practice.

And the best way to find opportunities is to work alongside people who are good at what they do and earn their respect and trust.

Posted: February 1st, 2009 under development.
Comments: none

This week, I’m presenting a paper at the Hawaii International Conference on System Sciences. My goal is to engage academic ethicists in a conversation about agile software development.

Given the year in employment I’ve had in the last year and what’s going on at my current employer this week, it is a gift that I was able to attend and I’m grateful for it.

Posted: January 4th, 2009 under development, scrum.
Comments: 1

The New York Times describes what happened to United Airlines stock value on September 8th, How a Series of Mistakes Hurt Shares of United

Investors wiped out $1 billion of the market value of UAL, United’s parent, within minutes of an erroneous news flash on Bloomberg screens about a United bankruptcy. Google and the Tribune Company, the owner of The South Florida Sun-Sentinel, whose Web site was the source of the article that led to the headline, soon blamed each other for causing the fiasco.

A chain of mistakes and vulnerabilities led to United Airlines six year old bankruptcy being reported as fresh news. Investors reacted, destroying value to the point that trading of UA stock had to be stopped until the situation could be cleared up.

Two features on a Tribune run website started the chain. One allowed an old article to appear in the most viewed box. The implementation apparently doesn’t prevent obscure articles from filtering to the top in off hours.

The second displayed the old article on the Sun-Sentinel site with today’s date but no original publish date.

Google crawled the article. It’s age and lack of original publish date confused the automated news search into interpreting the article as current.

Then a private analyst published it without independent verification. Then Bloomberg included that analyst’s report in their feed.

This led to the panic selling. Trading was resumed and the stock recovered much of its value but don’t mistake that many people lost alot of money.

The Times focuses on the relationship between newspapers and search engines. You can also focus on the pressure of news agencies to keep up with “breaking news” on various platforms. You can focus on a loss of discipline among editors.

I’d like to highlight how two casually implemented features on a website indirectly led to serious harm. I can’t imagine a print editor allowing an old article to appear without an original publish date. So how was it acceptable to allow online content to appear that way?

Given the relevancy algorithms Google is known to use, how much was the behavior of Tribune’s “most viewed” area intended to create exactly the behavior that backfired in this case, i.e. to create referential links back to Tribune for old content.

There’s plenty of blame to go around but how much sits with those who defined, accepted and implemented this behavior?

Posted: September 20th, 2008 under development.
Comments: none

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.

Posted: August 16th, 2008 under development.
Comments: none

Kallokain wrote a rebuttal to my post questioning the value of productivity metrics to justify agile.

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers.

I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. (read the post)

Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven’t seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect.

In my experience, measures that are tied to some non-revenue related abstract concept of “productivity” such as lines of code, story points, etc. are more problematic than helpful.

My point about velocity is that it is a measure that should be a feedback system back to the teams and becomes problematic if it is considered some sort of intrinsically meaningful measure that can be reported to senior executives (as in “We completed 20 story points last iteration, 25 this iteration. We’re five story points more efficient!”)

I agree that the ultimate measure of success in business is profit. I understand that any business decision should somehow influence revenue gains or hard dollar cost savings.

The problem with justifying an agile adoption based on revenue gains is there are so many other considerations that attempts to credit any single factor become dubious.

Cost savings need to be real not theoretical. Who did you lay off? How much budget did you give back based on agile adoption? Jeff Sutherland has a paper that does show significant cost savings using Scrum. The subject company was a CMMI-5 organization and there commitment and rigor to measurement was higher than most companies would support and is cost justified based on the government regulations they perform under.

If someone can propose a relevant metric that is economical for a small to medium size business to collect, that can be measured over time in small enough units to show increased performance due to specific process changes, that has some relation to reality that can be meaningfully communicated to senior managers, and doesn’t create more problems than it solves, I will be happy to consider it.

Posted: February 19th, 2008 under development.
Comments: none

Gerry spoke at the Microsoft Women’s Conference this week.

I joined her so that we could meet with some key players at Microsoft to talk about Ript™, our WPF application.

Attending were Henry Hahn, WPF Program Manager, Darren Mc Cormick, Worldwide UX Role Owner, and Katherine Westgate, a Marketing Officer from Microsoft’s NY office.

The conversation ranged over the whole history of our project: our Scrum/XP practices, how our team collaborates on user experience, how we created our product vision and our plan to monetize the product.

The three of them were entirely approachable, engaged and enthusiastic. They also came prepared. They’d all downloaded and worked with our application. Henry actually submitted feature suggestions from his team he knows are easy to implement given what we’ve already created.

Katherine helped pull the attendees together and lined up our hands on demo of Surface™. She was interested in figuring how our experiences with Ript™, agile software development and collaborative product ownership might help her enterprise clients. She also asked Gerry how Oxygen approaches advocacy for women, corporate good will and citizenship. Katherine is sharp and conscientious. I could tell Gerry hit it off with her.

Darren described the Developer Platform Evangelists (DPE) programs for joint marketing and developer assistance around products built in WPF and Silverlight. We discussed some of Microsoft’s goals for Silverlight distribution and what Oxygen’s next steps are to engage these resources. Darren is clearly passionate about user experience at the level of product, brand and within an organization. Yet another example of Microsoft going outside its organization to bring in new thinking.

Gerry’s main points were that women are the principle market for consumer technology, that usability testing with women provides valuable insight, how software should playful, purposeful, simple and accessible and how product development should not focus on early adopters but the people who will make up the vast majority of end users should the product be successful.

The conversation also ranged over tech issues. Henry is a fan of our application and left an open door for further communication. He said the .NET team is working on some of our core concerns:

• breaking up the .NET 3 installer into server and client modules making the package smaller
• improving the experience of their default install (it plays out like a windows update, hiding itself in the system tray – this is very confusing in an application install process)
• making it easier for ISV’s to run a silent install and wrap their own UI around the install
• improving cold start time
• providing more expressive API’s for automated UI testing

Don’t expect any of this soon unfortunately.

Clearly there are employees at Microsoft in leadership roles determined to engage with and support, not simply consume, innovative work originating outside the company. I had the same impression at the ALT.NET conference earlier this month.

This bodes well for both Microsoft’s future as well as for those of us looking to innovate in the marketplace using their tools and platforms.

Posted: October 26th, 2007 under Uncategorized.
Comments: none

At Oxygen, we have a team.

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

Posted: October 22nd, 2007 under Uncategorized.
Comments: 1

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.

Posted: September 21st, 2007 under scrum.
Comments: none

I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum, “Just Do It”.

Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”

Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.

But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.

Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.

Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.

It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.

Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.

Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?

All this to say “just do it” in knowledge work is bullshit. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.

Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.

Posted: September 16th, 2007 under scrum.
Comments: 4