The Third Bit

A funny-but-pointed ramble about Javascript, browser incompatibility, and the future of programming.

Uncategorized

SystemOne is a — well, I’m not sure, really.  A wiki?  A personal information manager?  But watch in this screencast as it dynamically updates search results as you add text to the page.  This is very cool…

…and it makes me wonder whether we should re-think how we define the curriculum for software engineering. Instead of listing topics, perhaps we should specify a handful of systems that we expect our graduates to be able to build, then work backward to figure out what skills they need.  And by “build”, I don’t just mean “write the Javascript”; I’m including requirements engineering, user interface design, performance analysis, quality assurance, integration — the whole nine balls of wax.

Uncategorized

The idea behind FriendsForFamilies is obvious in retrospect: use the technology of online dating to help families find other families with similar interests.  Just moved to a new city? Build a profile, then let their software find people who also like Buffy the Vampire Slayer, competitive swimming, and homemade pizza.  It’s just amazing no one thought of it before…

Uncategorized

The GTA’s Python User Group’s next meeting is Tuesday, Sept. 19.  This time around, there’ll be a pre-arranged speaker: Aaron Bentley (of Bazaar-NG fame) will be presenting a talk about the Sass web application wiki.

The meeting is at the regular time (6:30pm) on the Third Tuesday of  the Month (September 19th) at our regular location, the inimitable Linux Caffe (a great place to hack), on the corner of Grace and Harbord Streets.

More details: http://web.engcorp.com/pygta/wiki/NextMeeting

Uncategorized

The first TorCHI meeting of the academic year will be on Thursday, Sept 28, in Bahen 1230.  Khai Truong, a new professor in our department, will be talking about an audio-based reminder application.  For details, see the upcoming.org announcement.  I think this is a good chance for DemoCampers and other tech/entrepreneurial types in Toronto to meet and mingle with university types; look forward to seeing you there.

Uncategorized

CAS is IBM’s Centre for Advanced Studies; CASCON is an annual gathering of Canadian computer scientists and others that it organizes.  Attendance is free, and there are some very interesting workshops this year.  Here are a few highlights:
Monday Oct 16

• Agile for All: Supporting the Human Element in Agile Development
• AJAX (morning: intro; afternoon: the DOJO toolkit)

Tuesday Oct 17

• Writing for the Web
• Building a Ruby on Rails Application with DB2 Express
• Leveraging CELL: Proven Techniques, Common Issues and New Applications
• Tools for Managing Crosscutting Concerns

Wednesday Oct 18

• Social Computing: Best Practices
• Sense and Response Applications

Thursday Oct 19

• Third International Symposium on Software Engineering Course Projects
• Women in Technology: New Strategies to Attract a New Generation of Girls

The last two are the ones I most want to attend; it’s a shame they’re scheduled opposite one another.

Hope to see you there!

Uncategorized

Susan Baxter and others at the National Center for Genome Resources in the US have just published an article titled “Scientific Software Development Is Not An Oxymoron” in PLoS Computational Biology. It makes many of the same points as the Software Carpentry course, and includes pointers to examples of bioinformatics projects that meet the standards we expect of real science.

Update: “Not an Oxymoron” is the most-viewed article this week at PLoS Computational Biology!

Uncategorized

Let’s skip ahead to the last step: wrapping up. For most students, and most assignments, this means handing the work in and getting a grade. But course projects are different:

1. They often roll forward from one term to the next, so the end of one team’s involvement isn’t necessarily the end of the project; and
2. Course projects are meant to simulate real life, where delivery of a particular version is just another step in the product lifecycle.

In the past, I have asked teams to write a final report, which has been worth either 40% or 50% of their grade. These reports have ranged from a dozen to 50 pages, depending on the size and enthusiasm of the team. Typically, they have had the following sections:

• A title page, abstract, and table of contents. The first identifies the document; the second summarizes it in three or four sentences, so that busy browsers can decide whether they ought to read the whole thing; and the third helps people navigate. (A quick note on abstracts: for some reason, computer scientists often write movie trailers, rather than summaries. “We will contrast frobnication with jambramification” doesn’t help browsers who are faced with a hundred candidate links; “We show that frobnication is 28% more likely to spleedle than jamframification under normal circumstances” does.)
• An introduction which sets the stage for the rest of the document. This explains what problem the team set out to solve, and summarizes any background knowledge needed to understand the team’s solution. It shouldn’t state the obvious: there’s no need to tell readers what the Internet is, or how a parser works. Instead, it should cover whatever general knowledge the next team will need in order to continue the project.
• A description of what was done. This should not simply rehash the A&E (although that’s a good place to start). Instead, it should describe the system’s architecture, any features of its data formats, class structure, or UI that won’t immediately make sense to a knowledgeable observer, and so on. As with the introduction, the target audience is the next team to work on the project.
• An evaluation of the project. This should cover both how good the software is, and how well the team functioned. The first can include high-level criticism (“The persistence layer works fine, but in retrospect, our concurrency control mechanism was a bad choice”) and pointers to specifics (“Ticket 213 should be addressed before any further work is done on user preferences”). The second is actually the most important part of the entire course. What did the team learn about teamwork? What went well? What should they never do again? Motherhood-and-apple-pie statements about the importance of version control don’t belong here (or anywhere else). Instead, the team should conduct a proper post mortem, listing the good and bad points of the preceding thirteen weeks as honestly as they can.
• References, including books, papers, and links that the team found helpful.

As you can see, this report is neither a user’s guide nor maintenance documentation. Instead, it is like the end-of-contract reports I had to prepare when I was a consultant. What had I done to earn my customers’ money? What should the next person (who might not be me) do? What could I tell them that would save them time? Internal documentation (like Javadoc) doesn’t help with these questions, and anyway, the team should be producing that as they go along, not all in a rush at the end of term.

So, that’s what I’ve done in the past. This term, I’m going to try something different. Inspired in part by Karl Fogel’s Producing Open Source Software, I’m going to ask students to prepare some combination of the following:

1. An attractive home page, with a two-sentence mission statement and a few paragraphs or bullet lists to help newcomers orient themselves.
2. An FAQ.
3. An architectural overview, including block diagrams of the major components and a walkthrough of the processing cycle.
4. An installation guide.
5. An evaluation similar to those that have been included in previous terms’ reports.

All but the last will be written as DrProject wiki pages, so that the next team can pick up right where their predecessors left off. I hope this will give students a better feeling for what it would be like to work on a real long-lived project.

I’ll close with a few quotes from Fogel’s book:

…many projects don’t bother to standardize their installation procedures until very late int he game, telling themselves they can do it at any time: “We’ll sort all that stuff out when the code is closer to being ready.” What they don’t realize is that by putting off the boring work of finishing the build and installation procedures, they are actually makingg the code take longer to get ready… Boring work with a high payoff should always be done early. (pg. 26)

The importance of a bug tracking system lies not only in its usefulness to developers, but in what it signifies for project observers. For many people, an accessible bug database is one of the strongest signs that a project should be taken seriously. Furthermore, the higher the number of bugs in the database, the better the project looks. This might seem counterintuitive, but remember that the number of bugs recorded really depends on three things: the absolute number of bugs present in the software, the number of users using the software, and the convenience with which those users can register new bugs. Of these three factors, the latter two are more significant than the first. (pg. 26)

The ability to write clearly is perhaps the most important skill one can have in an open source environment. In the long run it matters more than programming talent. A great programmer with lousy communication skills can only get one thing done at a time, and even then may have trouble convincing others to pay attention. But a lousy programmer with good communication skills can coordinate and persuade many people to do many different things, and thereby have a significant effect on a project’s direction and momentum. (pg. 121)

Uncategorized

(Note: updates are at the bottom of the article.)

Nine years ago, when I first started writing for Doctor Dobb’s Journal, I decided to do a piece on the object-oriented features that were being added to MATLAB 5. I didn’t know much about them, so I called The MathWorks, told the publicity rep who I was, and asked if they could find me a co-author.

A couple of days later I got a call back from a woman who said she had volunteered to help with the article. I explained again who I was and what I wanted; she said she’d be happy to provide me with information and examples. I then said, “Thanks, but I’d rather have someone technical.” After a slight pause, she said, “Well, I have a master’s degree in Computer Science, and I implemented some of the new features.”

The rest of the conversation was short and uncomfortable. The next day, I had an email from a different guy saying that he’d be working with me. I was embarrassed at having put my foot in my mouth, but it was a long time before I thought to wonder how she had felt.

I’m telling this story because I think it’s a good way to introduce the single most important working practice for any software development team: respect. If you and your teammates don’t respect one another, it won’t matter what IDE you’re using, what programming language you’ve chosen, how carefully you take minutes during your meetings, or how accurate your schedule estimates are—by all measures except your final grade, you will fail.

People can be disrespectful on many levels. The most obvious is simple rudeness, which in student teams usually takes the form of interrupting people. I’ve been in meetings in which no one could get more than a sentence and a half out before someone would cut them off. The signal people send when they do that is that they think their teammates are less intelligent than they are. In fact, the reverse is usually true: if someone isn’t smart enough to realize that letting his teammates finish their thoughts is productive as well as polite, he’s probably just not smart, period.

I used “he” and “his” in the previous paragraph deliberately. In my experience, men are more likely to be disrespectful than women. They’re also more likely to disrespect who other people are, rather than what they’re saying or the work they’re doing, just like I did nine years ago.

What I see happening today is that the language of deep disrespect is coming back into fashion. Pushing the envelope has always been a key part of showing that you’re cool. Kids aren’t allowed to smoke cigarettes? To a 12-year-old, that’s reason enough to try it. Not allowed to call people “nigger” and “bitch”? That’s reason enough for Quentin Tarrentino to use the words twice a sentence in his movies. Rebellion is cool, man, so if you want to be cool, you have to rebel.

For a while, that was a good thing. In the year I was born (1963), being a rebel meant being opposed to racial segregation and big business, and supporting environmental causes and equal rights for women. In short, being cool meant being moral in the “do unto others” sense. Now that those rebels are the establishment, and their causes are orthodoxy, being cool means using “retro redneck” language, or saying things I thought I’d never hear again from anyone under 40 — things like, “Hey, man, if a woman isn’t tough enough to stand up for herself, maybe she shouldn’t be in the software business.”

Most of the men who act this way would vigorously deny that they’re racist, sexist, or homophobic. However, if you’re belong to one of the groups that those words were originally intended to bludgeon, how the hell do you tell? What’s the difference to Farouk, Ming, or Bruce between someone who really is racist, misogynist, or homophobic, and someone who just talks as if they were? They can’t tell that you mean it ironically; they can’t tell that it’s just a t-shirt to you, not a deeply-held belief. They particularly can’t tell it if they’ve only just met you, and most of their interactions with you are via email or chat.

A second, subtler, problem is the way that casual disrespect gives license to real disrespect. Some people really are bigots; some people really do think the way the guys working in the second-floor lab talk at one o’clock in the morning. Your insincere disrespect legitimizes theirs, because after all, they’re only going a little further than you.

Two more factoids, and then I’ll wrap up. First, it’s easy to see that fewer women go into Computer Science than men. What’s not easy to see is that the dropout rate among female students is higher than it is among males. This has nothing to do with intelligence, grades, or ability to do the work (and yes, there’s data to back that statement up). Instead, as many studies have shown (see for example Margolis and Fisher’s excllent Unlocking the Clubhouse), women are more likely to be made to feel that they don’t belong, or that computing isn’t for them. Even a small amount of unequal pressure can have a large result: if there’s just a 10% chance per year of a female student dropping out because the guys around her are listening to “Slap My Bitch Around” in the lab while working on their assignments, or because the guys on her CSC369 team have grabbed the interesting bits of implementation, and left the testing and documentation for her, then one third (1-(1-.1)⁴) of women will be gone after four years.

“Well, why doesn’t she grab the design stuff? Survival of the fittest, dude.” I’ve heard that argument many times, and my answer is always the same. If a 200-pound Phys Ed student came up to you, whacked you on the head, and took your wallet and iPod, you wouldn’t shrug and say, “Survival of the fittest.” The fact that what you’re doing doesn’t involve physical assault doesn’t make it any less unfair.

Second factoid: a couple of years ago, Michelle Levesque and I took a look at the gender ratio in open source. It was even more depressing than I expected: while the gender ratio in computing as a whole is about 7 to 1, the ratio in the open source community seems to be something like 200 or 300 to 1. In other words, the forces that are keeping women out of computing are 30 to 40 times more powerful in open source than in the industry as a whole. I don’t have any proof, but I suspect one reason is that there’s much less face-to-face contact in open source projects than in “conventional” ones. Study after study has shown that people are more likely to be rude by email than in person. You have to guard against this; you have to take a moment not to say some things, especially when you’re trying to juggle five different assignments and look for your first real job at the same time.

I’ve been talking mostly about the effects disrespect has on women, but it’s important to realize that the forces that make computing uncongenial for women also make it uncongenial for a lot of men. If you’re a guy with a well-balanced life who thinks social skills matter, you’re going to be subject to many of the same differential pressures as your female colleagues. I believe this is one of the reasons there’s so much bad software in the world: too many of the people who could make good user interfaces, and readable web sites, and elicit real requirements from customers, and provide useful technical support, are choosing to do other things with their lives.

One last story. The first time I taught CSC207, I had my students write a couple of five-line biographies for themselves as a way to get used to checking things into CVS. In the first, they were to describe who they were; in the second, they were to describe who they hoped to be in ten years’ time. A quarter of the male students made a point of mentioning their “beautiful” wife in the second bio; a few even specified that she was an actress or a model. Only one mentioned his “talented” wife, and he was already married. When I pointed this out to the class, they laughed; when I pointed out that half a century ago, in a similar exercise, a former teacher of mine had specified that she wanted to have both a Japanese gardener and a Chinese houseboy, because that was how you knew you’d made it in post-war Vancouver, they didn’t think it was quite as funny.

Respect.

• Part 1
• Part 2
• Part 3

Later: Sutha Kamal of Ambient Vector has written a post inspired by a conversation we had last week, which includes a pointer to this one by Leila Boujnane of Idee.

Later still: Chris Messina has a piece on the Future of Web Apps summit, titled “The Future of White Boy clubs”. I agree 100% with his statement that “…the future of the white boy club is in inclusivity one-upmanship”. Personally, I think we can consider the job done when our speakers’ lists look like the roster of MacArthur Genius Grant winners.

Even later: Michelle Levesque has posted about this, and refers to Suw’s excellent 12-step article on how to fix it. And yes, it is broken, and does need to be fixed.

Of course, it isn’t all serious.

Uncategorized

I paid a visit to the NanoHub at Purdue University yesterday, and in the discussion afterward, came up with what I think is an interesting value-add for application service providers.  Suppose you’re hosting programs for other people to use — in NanoHub’s case, a bunch of nanotechnology simulation and visualization tools.  Instead of running those programs “raw”, run them with a coverage analyzer, so that you can archive stats on which runs used which parts of the code.

This is useful information for the tools’ authors, since it tells them which parts of their code are actually being used, and which parts aren’t, but the real value is what happens when a bug is found.  Since coverage data has been archived, the tool’s authors can contact everyone whose results might have been affected and tell them they might have a problem.

Would computational scientists care?  My guess is yes, just as much as a chemist would care if she got a note from one of her suppliers saying that the last batch of bromium sulfide she’d been sent had been contaminated.  Would business application users?  I don’t know, but it’d be interesting to find out.

Uncategorized