The Third Bit

One of my apartment-mates back in grad school was an immunologist. She told me once about the first rule of public health: it’s only a cure if people will actually do it, or use it. For example, abstinence is not an effective way to prevent HIV/AIDS, or teenage pregnancy, because in practice, people won’t abstain.

I’ve thought about the difference between “works in the lab” and “works in the field” many times in the context of software engineering. Take the idea of doing rigorous up-front design using UML, for example; it sounds good, but I don’t know anyone who actually does it day-to-day, so I don’t count it as a “solution”. In contrast, while purists may sneer at test-driven development (TDD) as “hacking to solve hacking’s problems”, a growing number of people actually do it.

Which brings us to Future Email, a new web service that’ll send you messages at specified times to remind you to do things. We all use email as a to-do list to some extent; half of the messages in my inbox right now are things I’m supposed to take care of. But since it’s easy to overlook things that have been lying around for a while, Ben Sinclair has come up with the idea of pinging people when they most need the reminder. Simple, and a good fit for the way we actually work.

Uncategorized

Tuesday, 15 February 2005, 11:10AM -- Bahen Centre, Room 1180
Department of Computer Science
Speaker: Professor Allan Fisher, President and CEO of iCarnegie Inc.
Title: "Unlocking the Clubhouse: Women in Computing"

For those who don’t know their work, Jane Margolis and Allan Fisher set up a program at CMU to attract more female students to CS, and (just as importantly) to retain them. Their work is described in their book; I’m really looking forward to Allan’s talk.

Uncategorized

This C|Net story is depressing reading:

…the female share of bachelor’s degrees in computer science dropped from 37 percent in 1985 to 28 percent in 2001. And while women comprised 33 percent of information technology professionals in 1990, that figure was down to 26 percent in 2002… The drop is puzzling in part because women are making progress in related areas such as the natural sciences.

As Michelle Levesque and I said in an article last year, the situation’s even worse in open source. Hey, I wonder if it’s on the agenda for this year’s O’Reilly Open Source Conference? Hm, they seem to have left it out… again.

Equity

According to Jon Udell, Google Maps is even cooler than you think: if you append “output=xml” to any Google Maps URL, it’ll send you raw XML. Check out his most recent blog posting for an example of how you can use this.

Uncategorized

I read this in John Lewis Gaddis’s The Landscape of History on the way in this morning:

We are born, each of us, with such self-centeredness that only the fact of being babies, and therefore cute, saves us. Growing up is largely a matter of growing out of that condition: we soak in impressions, and as we do so we dethrone ourselves…from our original position at the center of the universe. [T]he establishment of identity requires recognizing our relative insignificance in the larger scheme of things… [T]hat’s what maturity means in human relationships—the arrival at identity by way of insignificance.

That kind of maturity is crucial to being a great programmer. I’ve had colleagues who could code rings around me, but who treated any criticism of what they’d written as a personal attack, and for whom winning the argument was more important than finding the truth. All of them had stopped learning—they could still absorb new facts, but not new ways of seeing the world.

I think the best way to prevent this is to get students used to reading each other’s code, and to having their code read and critiqued by peers (instead of by referees like TAs and instructors). This isn’t a new idea—many people have said that students should spend more time reading code than writing it, and that code reviews ought to be an integral part of undergraduate CS education. The problem is that it’s prohibitively labor-intensive. I can barely keep up with a group of nine (only half of whom are active on the mailing list); keeping up with a class of 80 or 120 would be physically impossible.

Perhaps this is the real reason people advocate pair programming. It isn’t about making sure that everyone on the team knows why the Fribble class has a pair of dictionaries as members; it’s about providing a constant reminder that there are other programmers in the universe, and that their view of that universe is as important as yours.

Uncategorized

In his recent blog posting, “Tenets of Transparency”, Eric Sink says that if independent software vendors (ISVs) aren’t willing to trust their customers, they won’t have any. When customers buy software from you, they trust that:

• your product will work on their machines;
• you will help them if they have problems;
• you will continue to improve the product;
• you will provide them with a reasonable and fairly-priced way of getting those improved versions;
• you are not going out of business anytime soon.

So, they have to trust you; Eric’s question is, how do you show that you trust them in return? His answers are:

1. Have a corporate weblog, so that customers can keep track of what’s really going on.
2. Offer web-based discussion forums, so that they can talk to you, and to each other.
3. Don’t hide your product’s problems.
4. Don’t annoy honest people with measures designed to block the dishonest few.
5. Offer a painless demo download.
6. Offer a money-back guarantee.
7. Share a little about your financial standing.
8. Talk about your future plans.

I’m not an ISV, but I am involved with some open source projects, and university courses, so how do they measure up on this scale? Most open source projects now have a weblog of some kind, and they’ve always had discussion forums; their problems are out in the open, they don’t include anti-piracy and licensing cruft, and the “demo” is the product itself.

But what about the money-back guarantee? As many people have observed, “free” software is only free if you think your time is worth nothing; you can easily waste hours or days trying to install, configure, and debug an open source package, and if you do, no one will give you that time back. As for Eric’s last two points, they’re mostly about giving people confidence that you’ll still be around next month or next year, so they won’t have to throw away what they’ve done and start over with some other package. Open source falls down here—except for very large projects (like Apache and Python), there’s a very real risk that people will lose interest, have to go earn a living, or squabble, all of which can lead to the project suddenly being dead in the water. Take Groovy, for example: twelve months ago, it was the Next Big Thing in Java, but now—well, there’s still a pulse, but I don’t think anyone’s expecting it to ever ship anything useful.

What about university courses? It may seem odd to compare them to commercial software, but I think it’s helpful to think of courses as products, which are “bought” when students enrol in them. Most courses don’t yet have a weblog, although Trac automatically generates one for my students’ CSC49X projects, and I’ll use one for course announcements the next time I teach a regular classroom course. Web-based discussion forums? Sure, we’ve all got those. Hiding the product’s problems? Well, students usually find problems (errors in notes, ambiguities in assignments) before profs do, and they’re encouraged to post their findings.

How about not annoying honest people for the sake of preventing dishonesty? I think this is one of the places where courses have to be measured differently from products. As instructors, our goal is to educate, but we’re also responsible for assessing students; we can only do that fairly if plagiarism and cheating are i, even if it means making honest students’ lives a little more difficult.

Offering a demo doesn’t really apply (unless you count keeping last term’s notes on-line, so that students can see what they’re getting themselves into). Offering a money-back guarantee is an interesting idea: when I was a student, I thought universities should let each graduating class vote on what their worst course had been, and refund their tuition for it. Now that I’m an instructor, I can see a lot wrong with that idea…

Financial standing? I don’t think it applies (although the next time I run a course, I’m going to keep track of how long it takes me to write lectures and create exercises, and post that on the course web site). Finally, I think it makes a lot of sense for instructors to talk about future plans, i.e., to tell students how the material they’re learning fits into what they’re going to do next term, next year, or after they graduate.

Teaching

Check out this new on-line store. Drag-and-drop with an unmodified browser? Coooolll…

Uncategorized

The French mathematician Blaise Pascal once wrote, “I have made this letter longer than usual, only because I have not had the time to make it shorter.” The ‘letter’ in question was a mathematical proof—Pascal was apologizing for not having taken the time to clean it up and make it more elegant.

Programmers often feel the same way about their programs. It’s not enough to make something work: we want it to be elegantly architected, and lightning fast. We rarely get a chance to make it either, though; there’s always something else that needs our attention.

I think that Extreme Programming’s emphasis on continuous refactoring is partly a reaction to this. There are lots of practical arguments in favor of pulling up weeds every time you touch a piece of code (see Michael Feathers’ Working Effectively with Legacy Code for an excellent guide to how best to go about doing this), but I think that’s all just post hoc rationalization. The real reason XPers to refactor is that they’re tired of shipping things that they’re not proud of.

I’m almost as tired of shipping (and marking) things that are slower than they ought to be. Tony Hoare might have been right when he said that, “Premature optimization is the root of all evil,” but never optimizing—never thinking about performance, never refactoring in order to get your program’s run-time from nineteen minutes to six seconds—is evil too.

The problem I face is that modern languages like Java and Python are harder to optimize than lower-level predecessors like Pascal and C. You’re further from the machine, which means you have to think harder to figure out what to change in order to achieve a particular effect. I’m therefore very interested in work being done in the Python community (and elsewhere) on speeding up these languages. Two particularly interesting approaches are specialization, as in Psyco, and mixed-language programming, as in Pyrex. I haven’t tried either on a real program yet, but once my students are finished their first round of changes to Trac, I’m going to see how much headway I can make with both.

Uncategorized

I don’t do, or agree with, everything in this post about what it’s like to be a consultant in the software industry, but I think it hits a lot of nails on their heads.

Uncategorized

I walked past a desk today, and saw that its occupant had written half a dozen passwords on the whiteboard beside him. That, and the break-in over the weekend, brought to mind this picture (found via Bruce Schneier’s blog on security). As Schneier says, “[I]t doesn’t matter what kind of security you implement if it’s easy to get around.”

Uncategorized