All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –


The Joel Test for Web Development

21 September 2004

Previously, I have asserted that web development is software development and that the lessons learned by the software industry can and should be applied to our own work. One good source of commentary on software development is Joel on Software. Joel takes a down-to-earth approach and communicates lucidly (his books come highly recommended, too). Based on his experience as a developer and running his own software company, Joel devised a quick test to help anyone rate the quality of their development team. You can read about it – in fact please go do that now. I’ll wait.

As the Joel Test is based on traditional software development, I though it would be interesting to try and apply it to a web development team (to my web development team), and see how we come out. Of course, some of the concepts need to be tweaked to apply more succinctly to typical web development, but hopefully between us (I welcome your feedback) we can come up with something close the The Joel Test for Web Development.

This is going to be lengthy, so I’ll run it over a few days. Here goes.

Do you use source control?

So we know about source control – I’ve written about it a few times before. Source control for web development is typically done using Microsoft’s Visual Source Safe or either CVS or Subversion (SVN). From experience you tend to find teams pick a platform and run with it (as is sensible), so ASP and ASP.NET shops tend to run VSS and developers working in PHP/Python/Perl/Ruby/whatever with go with either CVS or SVN.

That said, I suspect you’ll find that most smaller development teams cannot answer yes to this question. Whereas source control is pretty commonplace in software development, it’s less common for web development. This is probably because no-one’s figured out they’re writing software yet. We used to work like this, and figured that as there were only two of us doing the majority of the development we’d be ok. We’re using SVN on our current project. It works really well.

Can you make a build in one step?

This is one of those points that feels like it doesn’t apply to web development. However, it helps to read Joel’s point of clarification:

By this I mean: how many steps does it take to make a shipping build from the latest source snapshot?

This applies – the ‘shipping build’ in our case is a deployment of the app to a server. This could be for any number of reasons – you might need to deploy the app so that it can be tested, or so the client can demo it to investors, or whatever, the fact remains that deploying a web app is a pretty involved process. Steps for this generally include:

  • Taking a source snapshot
  • Taking a copy of the database, free from any junk data
  • Tweaking of configuration files so that file paths are correct for the new location
  • Moving the source to its new location
  • Importing the database dump into a clean database
  • Setting up a site or virtual site on the web server
  • Configuring any required DNS entries

Only when all that is done can you begin debugging any differences between the two, and if the servers aren’t specifically configured to be identical there’s bound to be a few differences. This process can be lengthy – for deploying to a new server for the first time I typically set aside a whole day. Subsequent deployments probably only take an hour or two. If this could be reduced to a one-step process, I’d save literally days of effort on each project. If I could get it down to a three-step process, even that would be supremely beneficial. Most importantly, the mere fact that there’s so much scope to make mistakes and miss out a step or two means that it really needs to be streamlined into byte-sized chunks.

Do you make daily builds?

In porting this test to a web development context, it’s important to get behind the reasoning for the question. The point of carrying out daily builds is to quickly spot bugs as they creep in. Fresh bugs are easier to fix than old ones, so it’s really important to be able to spot new bugs as they arise. The importance of this is directionally proportional to the severity of the bug, too – if someone’s broken a major piece of the application, you need to know ASAP.

What we’re talking about here is not the ability to deploy the app to a server every day, but the ability to check the integrity of the code at any point. If you’re using source control (yes, that old chestnut) this is surprisingly easy to do. You will invariably end up with a site for each developer, serving the files from their working copy so that they can test their changes before eventually checking them back into the source control. I use a naming scheme of for this. The simple solution is to set up yet another site (I use just running a ‘clean’ checkout of the files. Update the files daily from the source control, and you have yourself a testable daily build.

The story so far

- Drew McLellan


  1. § Jesse: Ok ok.. you have inspired me. Since we are just moving towards more serious PHP app development at my place of work I have wondered at what point do we want to manage this different? I’ll start thinking more about it next week ;) To provide my excuse – I have never had the support to do much but little hacks and such, now I find myself managing small application development.

    I think I am at the point where I need to do things a bit differently. At a guess, others creep into full blown app development the same way. First off make something like a form/mailer/feedback thing.. and then maybe an RSS creator/reader or two… now I want a system that pulls content from a DB into static pages and back again once edited with blah blah… It just snowballs as you discover PHP (or asp? nooo).
  2. § Peter Mount: Hi

    I’m glad this subject is being talked about. At TAFE (“Technical and Further Education” – a name for some tertiary schools in Australia) I had two semesters of classes in web development. I studied both ColdFusion and ASP.

    It really helped me that I’d already studied programming languages like Java and Visual Basic. Just having some background in programming logic was really appropriate. I’m really interested in the multi step process you’ve described. There are so many things mentioned here that I didn’t learn in my studies.

    The biggest point that hits me is “Web development is software development”. That sentence alone really summarises everything for me. Just as important, it’s the catch phrase I can use to explain web development to the people I know who wouldn’t otherwise understand.
  3. § Ivan Kurmanov: Web development is more than just software development and more that just web applications. Just let’s not mix different things. Web development may be design for web, it may be hand-coding HTML & CSS, it may be creating web standards, it may be creating publishing systems, which are not necessarily web-applications.

    Otherwise, isn’t it obvious that web application is software?
  4. § D Horse:

    Regarding “Do you make daily builds?” this applies equally to web applications and can be made more powerful if the daily build includes running all your unit, integration, and front end tests. There’s some pretty good open source software out there: try using something like Cruise Control with some Ant targets to automate the CVS/SVN checkout, build, test and deploy, and Selenium is worth a shot for automatically testing the front end of the web app. That way you can find out straight away if anyone has broken the build functionally – not just that it won’t compile. You can have cruise control/junit zip up a nice little report and have it emailed to the developers daily :) From personal experience it’s really handy – esp with bigger teams.


Work With Me logo

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

Follow me


  • 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 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 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, 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.