by - 0 comments

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.

by - 0 comments

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.”

by - 0 comments

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.

by - 1 Comment

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.

by - 0 comments

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.)

by - 2 Comments

Fun, or rather no fun, with generics (updated)

So, I understand that the following doesn’t work, but why doesn’t it work?

interface Adapter {}

class Adaptulator<I> {
    <e, A extends I & Adapter> void add(Class extl, Class<A> intl) {
    	addAdapterFactory(new AdapterFactory(extl, intl));
    }
}

The add() method gives me a compile error, “Cannot specify any additional bound Adapter when first bound is a type parameter” (in Eclipse), or “Type parameter cannot be followed by other bounds” (in IDEA), take your pick.

Clearly you’re just Not Allowed to use the type parameter I there, before the &, and that’s that. (And before you ask, it doesn’t work if you switch ’em, because there’s no guarantee that I isn’t a concrete class.) But why not? I’ve looked through Angelika Langer’s FAQ and can’t find an answer.

Generally when some generics limitation seems arbitrary, it’s because you’ve created a situation where the type system can’t actually enforce correctness. But I don’t see what case would break what I’m trying to do here. I’d say maybe it has something to do with method dispatch after type erasure, but there’s only one add() method, so it’s not like there’s any ambiguity…

So what’s the problem?

Update: I cross-posted this to stackoverflow.com, and Bruno De Fraine pointed out that the reason multiple bounds were introduced in the first place was to control the erasure. Since I is just going to erase to Object, it doesn’t get you anything there. Unfortunately, all I wanted was the compile-time type safety, so I’ll have to come up with something else…

by - 0 comments

Closures now please

I’m trying to fix the event handling in some table code someone else wrote a few months back (where “fix” here means “support an ugly legacy global event model without just calling fireTableDataChanged() for every little thing”). I pretty much know what I need it to do, but setting up the test expectations is seriously painful. Among other things, I’m having to crawl the table model to build up “expected” sets of rows and columns for each event, over and over again, with a slightly different crawl condition for each test.

Closures would make this clean, or at least easy. But we don’t have them, so instead it’s:

	private static interface ColMatcher {
		boolean matches(TableColumn col, int index);
	}

	private Set findColumns(ColMatcher matcher) {
		Set expectedCols = new HashSet();
		for (int col = 0, numCols = tableModel.getColumnCount(); col < numCols; col++) {
			TableColumn column = tableModel.getColumn(col);
			if (matcher.matches(column, col)) {
				expectedCols.add(col);
			}
		}
		return Collections.unmodifiableSet(expectedCols);
	}

and then, over and over again:

	public void testSomeLegacyEvent() {
		final Set expectedRows = ...;
		final Set expectedCols = findColumns(new ColMatcher() {
			@Override public boolean matches(TableColumn column, int index) {
				return /* some condition */;
			}
		});

		final NastyLegacyEvent e = ...;

		SwingUtilities.invokeAndWait(new Runnable() {
			@Override public void run() {
				nastyLegacyEventSystem.fireLegacyEvent(e);

				Set affectedColumns = tmListener.getAffectedColumns();
				assertEquals(expectedCols, affectedColumns);
				for (int col : expectedCols) {
					assertEquals(expectedRows, tmListener.getAffectedRows(col));
				}
			}
		});
	}

There’s really got to be a better way…