The Joel Test for Web Development
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 developer-name.project.dev for this. The simple solution is to set up yet another site (I use just project.dev) running a ‘clean’ checkout of the files. Update the files daily from the source control, and you have yourself a testable daily build.