Why Test With Random Data?

Guillaume Simard and François Fournier are writing Selenium tests for Basie. Over on the Basie blog, they explain why they’re using random data in their tests, rather than testing against predefined fixtures. What is your group using? And why?

The “Engineering” in Software Engineering

My first degree is in engineering, and while I’m too clumsy to have ever actually practiced [1], the courses I took still shape the way I look at things. In particular, I still enjoy articles like this one,which reports parse and load times for Javascript on various platforms. I really wish that a course on systems performance was a standard part of every undergrad CS degree; I doubt that’ll happen any time soon, but this stuff is out there if you look for it. And see also this post about scaling up Django — again, there’s lots of good engineering thinking on show.

[1] The scar on my right hand is from picking up a soldering iron the wrong way around twice in one afternoon.

Reuse, Reuse, Reuse

A former boss of mine had a sign on the wall in his office that said, “Out there, right now, someone is writing a queue and getting it wrong.”  What he meant was that if you’re using a mature language like Java or Python, you should never have to deal with textbook data structures, dates and times, currencies, and other things directly: someone else will always have been there first.  So, if you find yourself wrestling with timezones or passwords, fire up your favorite search engine and see what it turns up.

Fowler on Version Control

Martin Fowler has posted an article about version control systems —I don’t agree with everything he says, but it’s still a good, thoughtful overview.

I Guess I’m Unrealistic

I posted a link last week to Evan Robinson’s article explaining why crunch mode doesn’t work. Coincidentally, Ruben Ortega’s latest post on the ACM site asks, Why Do Software Developers Tolerate “Crunch Time”? His answer is “progress”, or at least, developers’ need to feel like they’re making progress. A couple of paragraphs later, though, he says:

It is unrealistic to deliver any project without going through some “Crunch time.”

I personally think that is the root of the problem. If you believe broken builds are inevitable, you’re not going to work very hard to make sure that code always compiles. If you believe that users are dumb, you’re not going to put much effort into fixing your user interface. And if you believe that it’s unrealistic to deliver code without all-nighters, guess what? You’re going to wind up pulling all-nighters.

So here’s my data. I haven’t stayed up to see the sunrise since the night my daughter was born, and you’d have to go back at least 15 years before that to my previous all-nighter. Despite that—no, because of that—I get a fair bit done on time and on spec. My algorithm is pretty simple:

1. List the things that need to be done.
2. Figure out which ones really matter, and which ones don’t.
3. Estimate how long each one is going to take.
4. Sort.
5. Start work.

For every thing I do, there’s a dozen that I set aside. I always feel a pang of regret (sometimes two), but trying to do everything is a good way to accomplish nothing. And while it took me twenty years to learn how, I’m not pretty good at abandoning things that are half done if it turns out that they’re not as important, or as doable, as I thought they were. (“I’ve started so I’ll finish” sounds macho, but it’s lousy project management.)

I’ve also learned to ask people, “Is this a good idea?” before I put too much work into it. This one was hard too; I’ve always enjoyed walking into a room and saying, “Ta da, look what I’ve done!” These days, though, I’ll ask my wife or a fellow prof or a student what they think before I start writing or coding. As my dad used to say, “A week of hard work can sometimes save you an hour of thought.”

So: what’s your strategy for getting things done? How well does it work? And do you think you’re getting better at it?

People You Don’t Want On Your Team

We’ve all met them, and from time to time, we’ve all been one of them…

Anna knows more about every subject than everyone else on the team put together—at least, she thinks she does. No matter what you say, she’ll correct you; no matter what you know, she knows better. Annas are pretty easy to spot: if you keep track in team meetings of how often people interrupt one another, her score is usually higher than everyone else’s put together.

Bao is a contrarian: no matter what anyone says, he’ll take the opposite side. This is healthy in small doses, but when Bao does it, there’s always another objection lurking behind the first half dozen.

Caitlin has so little confidence in her own ability (despite her good grades) that she won’t make any decision, no matter how small, until she has checked with someone else. Everything has to be spelled out in detail for her so that there’s no possibility of her getting anything wrong.

Frank believes that knowledge is power. He enjoys knowing things that other people don’t—or to be more accurate, he enjoys it when people know he knows things they don’t. Frank can actually make things work, but when asked how he did it, he’ll grin and say, “Oh, I’m sure you can figure it out.”

Hediyeh is quiet. Very quiet. She never speaks up in meetings, even when she knows that what other people are saying is wrong. She might contribute to the mailing list, but she’s very sensitive to criticism, and will always back down rather than defending her point of view. Hediyeh isn’t a troublemaker, but rather a lost opportunity.

Kenny is a hitchhiker. He has discovered that most people would rather shoulder some extra work than snitch, and he takes advantage of it at every turn. The frustrating thing is that he’s so damn plausible when someone finally does confront him. “There have been mistakes on all sides,” he says, or, “Well, I think you’re nit-picking.” The only way to deal with Kenny is to stand up to him: remember, if he’s not doing his share, he’s the bad guy, not you.

Melissa would easily have made the varsity procrastination team if she’d bothered to show up to tryouts. She means well—she really does feel bad about letting people down—but somehow something always comes up, and her tasks are never finished until the last possible moment. Of course, that means that everyone who is depending on her can’t do their work until after the last possible moment…

Petra‘s favorite phrase is “why don’t we”. Why don’t we write a GUI to help people edit the program’s configuration files? Hey, why don’t we invent our own little language for designing GUIs? Her energy and enthusiasm are hard to argue with, but argue you must. Otherwise, for every step you move forward, the project’s goalposts will recede by two. This is called feature creep, and has ruined many projects that might otherwise have delivered something small, but useful.

Raj is rude. “It’s just the way I talk,” he says, “If you can’t hack it, maybe you should find another team.” His favorite phrase is, “That’s stupid,” and he uses obscenity as aggressively as characters in Tarantino films. His only redeeming grace is that he can’t dissemble in front of the instructor as well as Kenny, so he’s easier to get rid of.

Sergei is simply incompetent. He doesn’t understand the problem, he hasn’t bothered to master the tools and libraries he’s supposed to be using, the code he checks in doesn’t compile, and his thirty-second bug fixes introduce more problems than they solve. If he means well, try to re-partition the work so that he’ll do less damage. If he doesn’t, he should be treated like any other hitchhiker.

All Nighters Lower Your Grades

I think every student should read Evan Robinson’s article “Why Crunch Mode Doesn’t Work“. It’s a short, readable summary of research into the effects of sleep deprivation, and very relevant to anyone who’s thinking about staying up until 3:30 a.m. to finish an assignment…

Adam on Selenium and HTTPS: Don’t

Adam Goucher (whom some of you met at the code sprint) has a new post up about the pain of testing with Selenium and HTTPS. I’m sure he’d be happy to answer questions…

Open Source Usability

Mark Guzdial’s blog on computing education is always worth reading; today, he reports on work by Prof. Mike Terry at Waterloo on usability in open source. The good news is, there’s lots of room to improve…

Free/Open Source Software Course in Australia

COMP8440 is a graduate-level course on free & open source software (FOSS). Lots of good material here; if you’re interested, you should also look at Karl Fogel’s Producing Open Source Software.

And while I’m posting links: Pierre Lafayette (a non-student working on Basie) sent a link to http://browsershots.org/, which will show you what your web pages look like in a bewildering variety of browsers on various platforms.