The Joel Test for Web Development - Part 3
This is the third part in a series looking at applying The Joel Test to a web development setting. You should read the first two before continuing, else you’ll think I’ve lost the plot and am about to start eating your rabbit.
Do programmers have quiet working conditions?
So, you’re now working to an up-to-date spec, you’re logging bugs effectively and fixing them as you go, you’re running to schedule and your source control system is keeping everything in check. If you could only hear yourself think you might be able to get some work done! This point really seams to go against the grain if your development environment is the general studio space of a creative company. Your co-workers may work best in a ‘lively’ atmosphere with music, chatting, phone conversations, maybe even video games (we try to keep ours in a separate room!), but it’s often very difficult to program in that environment. And that’s okay – it’s not your fault.
It’s a point that Joel raises, but something I’ve personally found to be true for the whole time I’ve been coding is that once I’ve got my head down and am in the zone, World War III (or even Burnout 3) could be going on behind me and I wouldn’t notice. However, the zone is a very difficult place to get to. If it’s noisy by the time I start work, there’s little hope of ever getting set in, and once I’m there, any small distraction like a phone call can knock me out.
Rule #1: never phone a developer when an email will do. Developers are not easily distracted by incoming email, yet a ringing phone demands attention NOW. Besides, developers don’t know how to operate office phones anyway.
There aren’t always easy solutions to conflicting needs in a working environment, however, if you find yourself wishing you could just work at home for a few days for the peace-and-quiet, you probably need to flag the issue with your boss sharpish. It’s his problem, not yours.
Do you use the best tools money can buy?
Traditional software development usually requires some pretty meaty tools. Last time I installed Visual Studio, for example, it came on about 308 DVDs and took around a week to complete. Compiling code takes processing power, and the more you’ve got the less time it takes so the more productive you will be. Us web developers, on the other hand, work mainly with text files. So who needs a quick computer for editing text files?
Us! The above would be a valid argument if web developers sat around writing a novel in a single text file all day, but that is obviously not the case. What we actually do a lot of is flicking around between applications. Your typical web dev set up will include a text editor with about 30 documents open, at least a couple of browsers with multiple tabs and windows, an email client, a database tool, either a shell or a Remote Deskop session to a development server, and optionally a graphics editor and perhaps a copy of Word with spec documents or source content. And what are we doing? Edit, save, switch, reload, switch, edit, save, switch, reload .. you know the drill. I don’t know about you, but the very last thing I try to do on a computer that is struggling under its own weight is switch between applications. To be productive, you need a machine that not only will happily run all of the above at once, but will be really bloody quick at switching between them. This means lots of memory, plenty of spare CPU, and a reasonable 2D graphics card (so that screen redraws are snappy). Disc space isn’t an issue.
The other factor that is really critical is what I like to call elbow room. Smarmy people call it ‘screen real estate’ and deserve a kicking, but the fact remains that when working with lots of documents, tools and browsers you need a lot of room on your screen. We’re talking high-res, baby. If anyone tells you that a single screen at 1024×768 is big enough for modern web development they are quite literally having a laugh. Doing so is both a productivity killer and an exercise in pure frustration. I’d suggest at least one screen at 1280×1024, and if you can add a second screen to the system, that’s even better. A second screen at 1024×786 will happily accommodate both your various browsers and your email client, and will keep your neck and shoulders from getting too stiff (seriously).
The last point on this topic is to say a computer that does this is so insanely cheap these days that nothing else makes sense. All of the above can be purchased from the retailer of your choice for less than 1000 units of the currency of your choice. (okay, smartarse, pounds/euros/dollars). The last Windows-based box I built as a web dev platform cost around 400 GBP, including tax. Making developers suffer with sub-standard technology is so much of a false economy that perpetrators should be stripped of their businesses on the spot.
Do you have testers?
Testing is one of those things that applies in pretty much the same way to all types of software development. I guess for web development a little more of the initial testing is carried out by the developer, due to the nature of the medium. However, don’t mistake “I wrote it, tried it and it worked” for testing on anything more than a superficial level. That’s not proper testing – for that you need someone who doesn’t know how the code works to try it under multiple circumstances, platforms, browsers, connection speeds, you know the drill. It’s like proof-reading your own work, you can’t do it accurately. Get testers.
Do new candidates write code during their interview?
A practical test at the interview stage is a really good way to assess someone’s competence and ability to do the job. However, the trick to getting good results (at least in my experience) is to make the situation as close to a genuine working situation as possible. Allow the candidate to look stuff up on the web. Leave some reference books with them too, if you like, but then get the hell out of there and give them a reasonable time to get the task done.
On returning, you can assess how far they’ve got through the task, and then sit down and ask them to talk you through what they’ve done. Ask them about the decisions they’ve made along the way. Ask if anything was problematic. Ask how they’d do it better if they did it again. Suggest improvements and see how they react to them. Be nice, it’s not a sport.
Do you do hallway usability testing?
Hallway usability testing is a term used to describe quick, informal usability tests. The idea is to grab the next person who walks by, show them what you’re working on and get feedback on how they think the interface works, or most importantly, should work. The point is that usability testing needn’t be an overly formal drawn-out process. Brief, low-effort testing as you go along can be extremely beneficial, and ultimately is so much more beneficial than forgetting about usability testing altogether.
In practise this is very easy to implement. The way we work it is that we bounce our ideas off each other, within the team. As there are only two of us on a project, we typically are working on very disparate parts of an app, and so neither of us is too familiar with the other’s area that our view of it is coloured. In other circumstances this wouldn’t work so well – but the crucial thing is to find some way to make quick usability tests easy to do, and then do them.
The story so far
Next time the conclusions, and hopefully fewer italics.