Noted without comment

Bruno S. Frey (1993), “Shirking or work morale? : The impact of regulating,” European Economic Review 37(8), 1523-1532, abstract:

Standard economics assumes that rational agents shirk, and that they have to be disciplined by monitoring and regulating. However, under specific circumstances regulating systematically worsens workers’ morale and thereby negatively affects their behavior. When a principal attributes a lower work morale to the agents than they actually have, an implicit contract is unilaterally violated and agents reduce their ‘excess morale’. This reaction is theoretically and empirically well supported by the notions of reciprocity and of overjustification. The theoretical propositions are applied to a specific employment relationship but hold more generally. They are consistent with empirical observations.

GeekGenderFail ’09

(X-posted to Chrononautic Log)

It’s good to know the science fiction community isn’t the only one capable of major fail, I guess. From Martin “Refactoring” Fowler, “Smut On Rails” (emphases added):

A couple of weeks ago there was a Ruby conference in San Francisco called GoGaRuCo (Golden Gate Ruby Conference). This conference has grabbed attention due to a talk at which the presenter illustrated a discussion of CouchDB by using sexually suggestive pictures of women. Unsurprisingly the result has been a fair bit of heated, and occasionally offensive, debate.

The main lines of the debate are familiar. Various people, not all women, lay the charge that the images and general tone was offensive. Such material makes women feel degraded and alienated. This kind of presentation would not be tolerated at most professional events.

Defenders of the presenter point out that the slides were humorous and no offense was intended. The Rails community has always had a edginess to it — in part because much of the Rails community is focused on the rejection of enterprise values — both technologically and socially. David Heinemeier Hansson is happy to proclaim himself as an R-rated individual and is happy to consign “professional” to the same pit to which he cast “enterprise”.

I’ll admit to finding much to like in the general edginess of the Rails world. Innovation often involves seeing a generally accepted line and vaulting over it. There’s plenty of precious posturing around the software world that I’m glad to see skewered. Many of us have been delighted at how Rails has cheekily whacked over-complex frameworks, vendor bloatware, and other assorted ills. An important target of this skewer has been the rise of corporate blandness, where a fear of offense has transformed into a fear of any authentic communication and the rise of the anodyne press release. I’m right with the Rails people on this — software is too much fun to shriveled up in dry talks and writing.

So the 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.

Except on this occasion I don’t see the suits as the people doing the complaining. Most of those calling foul are women who have had to struggle with very real sexism in their careers, and men who have seen this and side with those women. They have been fighting the suits since before the Rails leadership were born, and for much higher stakes.

This incident has now grown beyond a conference presentation and a slide-deck on the web. The issue is no longer the presentation, but the reaction of the community to this event. The leaders, particularly David Heinemeier Hansson as the most visible figure, now face an important time in influencing what the future of the community will be.

The reaction of the Rails leadership thus far is to deny the offense. I’ll say now that I don’t believe they are sexist. I believe that they didn’t think the talk would give this much offense — and even that they don’t think the talk should give offense.

At this point there’s an important principle. I can’t choose whether someone is offended by my actions. I can choose whether I care. The nub is that whatever the presenter may think, people were offended — both in the talk and those who saw the slides later. It doesn’t matter whether or not you think the slides were pornographic. The question is does the presenter, and the wider community, care that women feel disturbed, uncomfortable, marginalized and a little scared.

This is the kind of dickhead behavior that makes me hate programmers. It was evident at the last conference I went to (Javapolis ’08) but I sort of put it down to the organizer and chief offender being Belgian. Unfair of me. He was just being an undersocialized alpha geek. Beware the alpha geek; he will fuck your shit up.

There’s a metric crapload of technologies out there, and geeks have got a choice what they want to use, learn, work on, participate in. Funnily enough, Hansson’s handling of this little crisis reduces my interest in making Rails my next technology of choice by about 90%. His defenders would undoubtedly sneer at that, asking what kind of geek picks a technology for “non-technical” reasons. I’d ask: what kind of geek picks a technology that bets its future on alienating the smart half of the human race.


Update: Some follow-ups:

Neal Ford: “Lots of people who aren’t affected by this will say that this is a tempest in teapot, and that the offended parties are over reacting. Insidious misogyny is like lazy racism: people who engage in it hide behind a casual facade of ‘Oh, really, that was offensive?’ Yes, by the way, it was.”

Tim “XML” Bray: “When you offend people but didn’t mean to, you should just fucking well apologize. And do it in an unreserved way, unless you think that offending them is a good thing and will produce a result that you’re in favor of.”

Update again: A very good post from Virginia DeBolt at BlogHer, with further links: “A tipping point for women in tech? Here’s hoping.

Thank you…

…to whoever at Sun decided it would be a good idea for java.awt.geom.Point2D and java.awt.Point to override equals() and hashCode() even though they’re mutable. That’s four hours of my life I’m never going to get back.

Google officially now just another tech company

(X-posted to Chrononautic Log.)

Layoffs, office closings, and — most telling, I think anyone who’s been through a Silicon Valley inflection point will agree — the end of the free cafeteria.

Lean manufacturing sensei Jon Miller suggests five ways Google can avoid eliminating 100 jobs, but it’s probably too late.

There is nothing wrong with making engineering sites more effective and efficient. In fact that is what Google should look at doing before cutting back on their people, the source of ideas for improvement. Or maybe they don’t think of recruiters as sources of creative ideas, only engineers and R&D people. That is a typical, if incorrect, point of view among managers of knowledge workers. Rationalizing job cuts is a very tough thing that many of us are having to do. Is it evil?

I googled evil: that which causes harm or destruction or misfortune

Google shouldn’t be the source of harm, destruction or misfortune to others. That is a hard path to walk as a for profit business in a free market economy. Competition can be destructive and bring misfortune to others. But it’s the path of their choice so Google should walk it and not just talk it.

Software is fiction

It’s hard for me to believe I’ve never run across Richard Gabriel’s essay Lessons from the Science of Nothing at All before.

Suppose you wanted to design and build a gas stove, but no one had ever used gas to cook with before. In fact, assume that before this, all that had ever been used was a wood stove.

Here are some things you wouldn’t know: Will you use the gas flame to heat a piece of metal on which the pots and pans will sit, and that metal will transfer the heat, or will the flame be applied directly to the pots and pans? How will you control the temperature? Will you require that people move their pans from places of intense heat to places of less heat? Will you provide a gas flow controller that will reduce the amount of fuel to the flame? Will you move the flame closer or farther away from the pan or heat transfer metal? Will the heat be a manageable temperature for all kinds of cooking or only for limited use? Will cooks be afraid of using gas? How will you get it into the stove? Will it be stored or continuously supplied? How will you control the temperature of an oven using gas? Will a stove designed this way be affordable? Will the stove explode? Will the gas smell funny? Will the stove need to be inside or outside the house?

There are thousands of questions like this in every software project I’m calling unpredictable, and I’m also claiming that almost all software projects are unpredictable.

(Via Tim Bray.)

Lean software development

The other groups at my current employer make fun of our group for having too many meetings. Our group makes fun of them for not getting anything done. (Okay, I’m exaggerating. Mostly.) But it’s true that meetings — however helpful they might be in keeping the stakeholders (or in XP terms, “customers”) and the developers on the same page — aren’t development. In lean manufacturing terms, meetings are waste.

I’ve talked to Jon at Gemba a few times over the years about how lean manufacturing techniques might be applied to software development, and I’ve always been a bit wishy-washy about it — somewhere between “well, agile is kind of like lean” and “how far can you really go applying techniques for repeatable operations on physical objects to something as variable and metaphysical as software, anyway?”

Now — well, actually, some time back, it looks like — along comes David Anderson, formerly of Microsoft, now of Corbis (the Getty Images competitor that Bill Gates originally set up specifically to digitize the stuff he wanted on the flat panels in his mansion), who’s not just scratching his head and talking about it, he’s doing it. With a fifty-person team and great success, apparently.

There are some tweaks. Cross-training is harder when you’ve got specialized business analysts (accountants, graphics people). Tasks are inherently variable, so there’s not really any concept of takt time. But a lot carries over, and while (if I do say so myself) I think my group’s process is already pretty lean-ish and — being that we get a lot done, keep our customers happy, and all always go home at reasonable hours — pretty damn good, I can already see where we could borrow stuff from Anderson’s kanban system to make it even better.