Adam Bosworth: “All successful standards are as simple as possible, not as hard as possible.” Required reading.

It is amazing how easy it is to sail through a Computer Science degree from a top university without ever learning the basic tools of software developers, without ever working on a team, and without ever taking a course for which you don’t get an automatic F for collaborating. Many CS departments are trapped in the 1980s, teaching the same old curriculum that has by now become completely divorced from the reality of modern software development.

Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?

Many universities have managed to convince themselves that the more irrelevant the curriculum is to the real world, the more elite they are. It’s the liberal arts way. Leave it to the technical vocational institutes, the red-brick universities, and the lesser schools endowed with many compass points (“University of Northern Southwest Florida”) to actually produce programmers. The Ivy Leagues of the world want to teach linear algebra and theories of computation and Haskell programming, and all the striver CS departments trying to raise their standards are doing so by eliminating anything practical from the curriculum in favor of more theory.

Now, don’t get me wrong, this isn’t necessarily a bad thing. At least they’re replacing Java with Scheme, if only because “that’s what MIT does.” (Too late!) And they are teaching students to think a certain way. And given how much the average CS professor knows about real-world software engineering, I think I’d rather have kids learn that stuff at an internship at Fog Creek.

Greg Wilson, an assistant professor at the University of Toronto, gave a talk at the StackOverflow DevDay conference in Toronto, which was entertaining, informative, and generally just a huge hit. We got to talking, and he told me about his latest brainchild, UCOSP, which stands for “All The Good Names Are Taken.”

It’s a consortium of 15 universities, mostly in Canada, which are organizing joint senior-year capstone projects. They’re setting up teams of a half-dozen undergraduates from assorted universities to collaborate on contributing to an open source project, for credit and for a grade. As soon as I heard about the program I volunteered to sponsor a team to make a contribution to Mercurial. Sponsoring a team consists of offering to pay for a trip to Toronto for all the undergrads to get organized, and providing a programmer to mentor the team.

Browsing around the UCOSP blog, I was reminded of why student projects, while laudatory, frequently fail to deliver anything useful. “One of the points of this course is to give you a chance to find out what it’s like to set and then meet your own goals,” Greg wrote. “The net result is pretty clear at this point: in many cases, students are doing less per week on this course than they would on a more structured course that had exactly the same content.”

College students in their final year have about 16 years of experience doing short projects and leaving everything until the last minute. Until you’re a senior in college, you’re very unlikely to have ever encountered an assignment that can’t be done by staying up all night.

The typical CS assignment expects students to write the “interesting” part of the code (in the academic sense of the word). The other 90% of the work that it takes to bring code up to the level of “useful, real-world code” is never expected from undergrads, because it’s not “interesting” to fix bugs and deal with real-world conditions, and because most CS faculty have never worked in the real world and have almost no idea what it takes to create software that can survive an encounter with users.

Time management is usually to blame. In a group of four students, even if one or two of the students are enterprising enough to try to start early in the term, the other students are likely to drag their heels, because they have more urgent projects from other classes that are due tomorrow. The enterprising student(s) will then have to choose between starting first and doing more than their fair share of the work, or waiting with everyone else until the night before, and guess which wins.

Students have exactly zero experience with long term, team-based schedules. Therefore, they almost always do crappy work when given a term-length project and told to manage their time themselves.

If anything productive is to come out of these kinds of projects, you have to have weekly deadlines, and you have to recognize that ALL the work for the project will be done the night before the weekly deadline. It appears to be a permanent part of the human condition that long term deadlines without short term milestones are rarely met.

This might be a neat opportunity to use Scrum. Once a week, the team gets together, in person or virtually, and reviews the previous week’s work. Then they decide which features and tasks to do over the next week. FogBugz would work great for tracking this: if you’re doing a capstone project and need access to FogBugz, please let us know and we’ll be happy to set you up for free. We can also set you up with beta access to kiln, our hosted version of Mercurial, which includes a code review feature.

I’ve been blaming students, here, for lacking the discipline to do term-length projects throughout the term, instead of procrastinating, but of course, the problem is endemic among non-students as well. It’s taken me a while, but I finally learned that long-term deadlines (or no deadlines at all) just don’t work with professional programmers, either: you need a schedule of regular, frequent deliverables to be productive over the long term. The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.

Why does WiFi work so poorly at tech conferences?

Marcus GriepI assume that WiFi wasn’t really designed to handle a big ballroom with 2000 people, all trying to connect with their laptops and cell phones at the same time. Sometimes I feel like I’m lucky if it works in my apartment. So I never thought it was even possible to get it to work at a large, technically-savvy conference. At Stack Overflow DevDays, yesterday in Boston, the bandwidth seemed OK but the DHCP server ran out of addresses. This didn’t seem to be something that anyone could fix. The conference organizers (er, me and Greg) were incredibly busy trying to, you know, organize the conference, so spending time tracking down the mysterious ISP and making them fix their router was impossible.

It’s almost getting boring to read the conference reports complaining about this. Almost every conference, even the ones put on by fancy tech companies, has trouble. I never assume WiFi is going to work whenever I’m in a room with that many techies.

At the smaller conferences, the ones with, say, 300-1000 people, the trouble is that internet access is something of a black box. If you’re a conference organizer, your first priority is finding a space—any space—because there usually aren’t a lot of options. For example if you want to put on an event for 500 people in Seattle, there are probably 20 hotels that can accomodate you and maybe 10 other non-hotel venues. For the date you want, 3/4s of them are booked. You end up choosing between three options, if you’re really lucky. The venue with the best Internet access would be nice, but there are so many other considerations that you don’t really think about this when you’re booking the space. Besides, all the venues tell you they have fantastic, soo-perb A-number-1 internet access. When you try to ask complicated questions and explain that your conference has a lot of techies, they say, yes, we understand, we have A-number-1 internet access, no problem very good. When you say, “Yeah, but have you configured your DHCP server so that it has more than the default 254 IP addresses available to hand out,” they have no idea what on earth you’re talking about, and of course it turns out that they had some vendor, a company you’ve never heard of, provide their internet access. And half the time, that vendor installed a DSL line from the local telco and hooked it up to a LinkSys WRT54g they got at Costco, then installed some kind of crappola welcome-screen software just to make it even worse, and then disappeared.

Marcus GriepThere are steps that can be taken. Here’s an interesting study [PDF] done by Intel about making WiFi work at large conferences. The best idea I got from that was that there should be as many hardwired network access points as possible, to get the heavy users off the air, because ethernet has way more bandwidth. There are companies that specialize in making WiFi systems that will support large conferences: one that I found is called Meraki; I don’t know much about them but their website sure makes it seem like they understand the issues at least.

At the very least, though, a venue should be able to tell you how many access points they actually have (if it’s just one, you’ve got problems), whether they are managed access points or not, whether dedicated ports with higher priority can be provided for the speakers and for journalists that do not share bandwidth with the audience, how many IP addresses the DHCP server can provide, the total number of people that can be online at once, and the amount of bandwidth available to the entire site. If you can’t get good answers to these questions before the conference begins, you have to assume that they’ll be running a single, consumer router connected to a DSL line and that’s about all you get.

What are some of the best practices for conference organizers? What questions should they ask the conference venue or ISP to know, in advance, if the WiFi is going to work? What are the most common causes of crappy WiFi at conferences? Are they avoidable, or is WiFi simply not an adequate technology for large conferences? I thought I’d ask on ServerFault, so if you have any ideas, have at it!