In this episode of the podcast, Joel and Jeff discuss lessons from a year of building Stack Overflow, the mysteries of COBOL, some YSlow website optimizations, and magic numbers.
What have we learned in a year of building Stack Overflow? If someone wanted to design a system like Stack overflow, I'd give them these two pieces of advice. First, never have any unbounded behavior in your website. Anywhere. Bounding, velocity and rate limiting, should be pervasive throughout your design from day one. Second, provide an outlet for meta discussion from day one. Unless you provide a teacher's lounge, or afterschool activities for the students, you haven't completed the experience.
In our experience, the best way to manage online behavior is to make the positive behaviors fun and rewarding. If you do this right, the bad and negative behaviors fall by the wayside. (Although you also, regrettably, will still need tools for dealing with rare but aberrant behavior.)
Neither Joel or I have ever met a COBOL programmer. That's why we're skeptical of these dramatic claims that the world is overrun with invisible COBOL code. There are, surprisingly, some good COBOL questions on Stack Overflow, but it's a tiny fraction.
How much COBOL code can you fit in the 1 megabyte (at most!) memory that these 60's and 70's era servers had? Or the tiny hard drives?
Is what happened to COBOL programmers eventually what happens to all programmers? Take SQL as an example. If you have 256 gigabytes of main memory -- not very expensive already, and getting cheaper every day -- is all that SQL and disk stuff still relevant?
We recently spent some time improving performance on Stack Overflow, and as always we've learned that whatever we think is slow, is not, and the part that is slow is in a totally unexpected area of our code. Never assume you know where a performance problem is, because I can almost guarantee you're wrong. Profile it and look at the data!
We've seen huge benefits, more than anticipated, by moving our static web content to a seperate, cookieless domain. (We registered sstatic.net for this purpose, which explains the rationale.) This is one of the key recommendations from tools like YSlow and Google Page Speed. It's a surprisingly effective form of poor man's web farm scaling.
A brief digression into the "why does anyone still use IE6" argument. Here's Microsoft's official position, as crazy as it may seem.
We may be at the end of the road for the low hanging fruit of website performance optimizations. Of course we can always buy faster hardware. But that doesn't fix the speed of light problem. Given our large international audience, I sort of wish we could have multiple server farms in different geographic locations, but that may be quite a long way off.
Computer "magic number" number bugs are kind of fun; you may remember a very public Excel bug in this vein. Joel once got a credit card with an expiration date set in 2049, which is technically valid, but it barely worked anywhere.
Our favorite questions this week:
Is 23,148,855,308,184,500 a magic number, or sheer chance? A fascinating tale of programmer number forensics.
How to learn Cobol. OK, but first of all, why in the world would you want to do this?
If you'd like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to email@example.com. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879.
The transcript wiki for this episode is available for public editing.