All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –

About

The Joel Test for Web Development - Part 3

26 September 2004

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.

- Drew McLellan

Comments

  1. § Felipe:

    Thank you, this is a great post. I’m always surprised that web development maturity takes so long to complete.

    Our company now passes the test in most of the elements, but then, in 2009 it’s been 5 years since your post.

    Felipe

Photographs

Work With Me

edgeofmyseat.com logo

At edgeofmyseat.com we build custom content management systems, ecommerce solutions and develop web apps.

Follow me

Affiliation

  • Web Standards Project
  • Britpack
  • 24 ways

Perch - a really little cms

About Drew McLellan

Photo of Drew McLellan

Drew McLellan (@drewm) has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he’s spread himself between both front- and back-end development projects, and now is Director and Senior Web Developer at edgeofmyseat.com in Maidenhead, UK (GEO: 51.5217, -0.7177). Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within design and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Cadburys, ICI Dulux and Virgin.net. Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public appearances, fame, glory, and his eventual downfall.

Picking himself up again, Drew is now a strong advocate for best practises, and stood as Group Lead for The Web Standards Project 2006-08. He has had articles published by A List Apart, Adobe, and O’Reilly Media’s XML.com, mostly due to mistaken identity. Drew is a proponent of the lower-case semantic web, and is currently expending energies in the direction of the microformats movement, with particular interests in making parsers an off-the-shelf commodity and developing simple UI conventions. He writes here at all in the head and, with a little help from his friends, at 24 ways.