Summary: This is the 38th episode of the StackOverflow podcast, where Joel and Jeff discuss YSlow optimizations for large websites, the value of unit testing, and the hidden pitfalls of asking questions to programmers. Joel notes that simply paying attention to what your coworkers are doing is an effective way to build and lead a team. If you aren’t interested in what your teammates are doing.. why are you on that team, again? I’ve followed the excellent Yahoo YSlow tool for a while. It really is intended for large scale websites, as I’ve noted before. But Stack Overflow is exactly the type of website that can benefit from YSlow recommendations! We’ve been using the Expires or Cache-Control Header since we launched. This saves the browser round-trips when getting infrequently changing items, such as images, javascript, or css. The downside is that, when you do actually change these files, you have to remember to change the filenames. A part of our build process now “tags” these files with a version number so we no longer have to remember to do this manually. We also integrated the YUI Compressor into our build, to minify our CSS and JavaScript resources. We had bad luck with the .NET port of this tool, so we just shell out to Java in the build. Works great, although we had some crazy pathing issues that made us put the JAR file in the root. It’s also possible for Google to host your shared javascript files, if you’re using a popular third party JS library. We chose not to do this because we package related JavaScript together, so it would defeat the benefits of packaging. Browsers will parallelize their requests, but only so many requests can be “in flight” to the same domain. So it can be wise to split your website components across domains. Simple aliases such as a.mydomain.com seem to work fine for this purpose. Joel explains CSS sprites, which is an effective way to minimize the number of HTTP requests your website is generating. This is particularly useful on toolbars and the like which contain a lot of related images. There are analogs here in the Strings tab of Process Explorer, and the UNIX command Strings, as well as classic Windows resource browsing — spelunking for whatever icons and image resources you can find in a file. This is all important because I want Stack Overflow to be as fast as possible. Performance is a feature, and I think often underestimated. Even half a second delay can cause a 20% drop in traffic. We discuss differential database backups and DNS time to live, to make the upcoming site transition to new harware as painless as possible, and minimize downtime. We’ll also update the old site with a static HTML page that tells you you need to flush your DNS. Joel notes that his partner Michael had to order thermal compound back in 2000 when he built up PCs for Fog Creek. This stuff is important! Please don’t use vegemite. We finally fixed our paging algorithm, which had some aggravating edge condition bugs. I dedicate this fix to John Topley. Joel and I have some reservations about unit testing, at least the dogmatic test-first kind, where your goal is to have code coverage in the 95%+ range. It seems to us that this works best for legacy type applications that aren’t changing very much. At some level, the tests become friction preventing you from making changes, as every change results in a stack of failing tests. Joel talks about Robert Martin’s (aka Uncle Bob) Solid Principles, as explained on a recent Hanselminutes podcast. Joel: “it sounded like extremely bureaucratic programming” that “could theoretically protect you against things, but You Aren’t Gonna Need It.” On the other hand, if you’re building a framework or API, something designed to be used by thousands or millions of developers, then having a lot of unit tests — or Uncle Bob’s Principles of OOD [...]
