The Joel Test for Web Development - Part 2
This is the second part in a series looking at applying The Joel Test to a web development setting. You should read the opening part before continuing, else you’ll think I’m a crazy loon.
Do you have a bug database?
So, once you’ve got your daily builds going and are hopefully performing daily testing on any new code, you’ll be spotting new bugs. There’s no shame in having bugs. They’re a daily part of development work and merely a symptom of the human tendency not to be perfect. The shame is in not documenting them sufficiently so that they can be fixed without hassle. For this, you need a bug database.
Bug databases have to work on a couple of levels. Firstly they have to cater to the needs of the developer. A developer should be able to log bugs in his own or a colleagues work with comprehensive technical detail. On the other hand you have your regular testers. Typically these folk don’t have the technical expertise to explain why something has gone wrong, only that they tried xyz and it didn’t work. Your bug database has to be easy to use and able to tease as much information out of these non-technical users as possible. It’s actually not so hard.
We use a web-based tool called Mantis, but there are lots of options out there. Joel has one of his own, Trac is another excellent option (I’m looking at switching to this), and there are plenty more besides.
Do you fix bugs before writing new code?
I asserted in the first part of this article that new bugs are easier to fix than old ones. This is a Joel-ism which I won’t try to re-explain, just go read the corresponding item on The Joel Test. This has to apply to web development pretty well – all the points about forgetting how code works and having to relearn the process before beginning to look for the bug all ring true.
Personally, I can’t say that I adhere to this rule 100% at the moment, but my tendency is to fix bugs as soon as I spot them. That is, unless they look tricky when I’ll leave them for Some Better Day.
Do you have an up-to-date schedule?
Ohboy, schedules. Estimating development hours is always impossibly difficult. I find that breaking the schedule up into broad chunks of functionality rather than anything too specific helps to both keep the project on track and stop me getting depressed whenever something small runs over, even though there may be no impact to the overall timeline. Estimating hours for ‘user authentication system’ is a lot easier than ‘forgotten password script’, for example.
The key point here is making sure the schedule is kept up to date. An out of date schedule is about as useful as having no schedule at all, and if things genuinely take longer than you estimated, it’s amazing how little people mind sometimes when they have plenty of notice.
Do you have a spec?
One great aspect about working on regular web site projects is that changes are often very easy and quick to make. Of course, this doesn’t necessarily hold true for application development, where a change that may be perceived as small from the outside and involve significant restructuring and hours or wasted work. The danger being that those you’re working with might not recognise that they’re commissioning software development – they may well still be in a standard web site mindset.
It is here that the spec is your friend. By documenting the whole application before you start writing any code, you give yourself the best possible chance of not having to refactor the entire application midway through. Naturally, when working on larger projects it’s common to think of things you’d not previously considered once you get into the nitty-gritty of the app. Getting into the nitty-gritty on paper first enables those changes to be made where they are cheap to make.
We tend to run a couple of different of spec documents on projects at work. The first is a Functional Specification which describes all the features the application will have, how each of those features works and what tasks the user can achieve with them. This is the document that enables the client to see that the proposed application will meet the needs and requirements they are trying to address. The second is a Screen Specification. This details literally each screen of the application, the data that screen collects and the data it displays. This document is reenforced with a flat graphic or HTML-only build of each main screen so that the client can see what their getting. Once all that is signed off, we begin the build, updating the documents as we go to reflect any minor tweaks and changes so that the documents reflect the application at the end as well as they did in the beginning.
To be continued …