Critical Code Studies

I blame the jet lag for the fact that I honestly can’t tell whether these folks are serious or not.

The blog is dedicated to exploring interpretations of computer code within cultural contexts. Rather than focusing primarily on making code function or even the pursuit of “beautiful” code, critical code studies brings in critical theory to examine the ways in which the lines of code reflect, shape, and reproduce our culture including aspects of class, gender, race, sexuality. These criticisms include both the context for the code’s creation and the ways in which it circulates in culture.

I can totally see class. And I can’t help but think there must be something vaguely gendered, if only in a male-centric, locker-room-homophobia sort of way, about the whole Mort question

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.

Link roundup

Sad, I know. I had dreams of getting some serious blogging done while I was on vacation, but they all vanished in a haze of roadside attractions and chile rellenos. Instead, you get these tidbits:

  • Steve Yegge says “the worst thing that can happen to a code base is size.” I don’t know why he had so much trouble with Eclipse — I’m looking at… find, find, wc, awk… just under 7000 classes and a million lines of code and it seems to work fine for me — but he’s got a point. At my last job, with about half that much code, we were able, just barely, to take our organically grown mess and decompose it into sensible layers and functional units, when a new choice of tools (WebLogic Workshop) forced us to, and it took half a dozen developers a month. If we tried it here, I wouldn’t be too suprised to see it take four.
  • In the wake of the Javapolis closure discussions (notes forthcoming — no, really), Bruce Eckel thinks that “Once you bind yourself to backwards compatibility with anything, you must be prepared for your language to be corrupted as you add features. If Java is unwilling to break backwards compatibility, then it is inevitable that it will acquire both unproductive complexity and incomplete implementation of new features.” True dat. But up against it, well — did I mention a million lines of code? It seems like there’s an unsolved problem somewhere in there, about the evolution of large systems. (And no, Ben, switching to a job where everything is a small one-off consulting project isn’t always the answer. 🙂 )
  • Martin Fowler finds that clients (as in, customers) can’t be trusted to keep the test bar green. Maybe ThoughtWorks ought to write it into their contracts that they’ll charge for the time it takes to get the bar green again before making any enhancements.
  • Tim Bray has some thoughts on providing wireless at conferences. Javapolis was my first experience with a fully (rather flakily, especially when two thousand people would all simultaneously leave a session and start checking email, but) wifi-enabled conference, and overall I agree with Bray that it’s a big plus. This isn’t school; your audience doesn’t have to be here, and if you can’t keep them interested, you shouldn’t be speaking. Mostly I wish I’d screwed around more during the conference, not less — maybe I’d have discovered in time to ask James Ward about it that FlexBuilder (contra the Flex docs) doesn’t let you assign to a const field in the constructor.

When I have time and I’m sufficiently awake, I’ll post something interesting, like Ben’s experiment with closures in JavaScript.