All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –

About

The Joel Test for Web Development - Part 2

22 September 2004

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 …

The story so far

- Drew McLellan

Comments

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

I made

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.