Comments on: Adapting The Joel Test To Web Development

By: Fake51

Fake51 — Fri, 06 Nov 2009 13:45:31 +0000

I agree with most of the points on the list and find it a good tool to judge yourself (as well as others) by. There are a couple of things I’d be less absolute about.

The build process can easily, as has been stated before, be handled via SVN. It’s actually rather easy to setup your SVN server with access handling so that given clients can only read from your repo, not write to it. Which means that if you don’t update it, they won’t have access to anything they wouldn’t have access to otherwise. And you keep the ease-of-use that is the svn update.

Also, there are times when clients will be screaming at you for a given feature. Telling them that bugs must be fixed first is not the best way to handle the issue. I guess the difference here is between working continuously for the same client and then shipping new products to existing/new clients: if you have the luxury of spending time between versions working on your product, then by all means, fix those bugs – but if you’re working a site for a client, and they all of a sudden need that wicked, new feature to promote something or other, then get that implemented instead of trying to fix some bug in the backend. Otherwise you’ll see your clients looking for someone that handles their priorities better.

Btw, how does catering lunch equal paying for necessary tools? Just wondering :)

By: Ivo

Ivo — Thu, 05 Nov 2009 09:01:10 +0000

If you’re interested in PHP and the Joel Test, you might also enjoy this presentation by Lorna Mitchell:

http://www.slideshare.net/lornajane/passing-the-joel-test-in-the-php-world

By: pbg

pbg — Thu, 05 Nov 2009 00:09:07 +0000

Hi Brandon, I really have been enjoying what you have been writing about lately. You point out a very important part of the software industry, especially in our field, that is in dire need of some updating. It is better to inverse the process as you are suggesting by asking the employer what they have in place for YOU. Its even more important, I think, to out flaky employers, clients, projects, because developers can be used, wasted, and exploited in poor quality environments.
It really seems that for our time the Joel test is broken. Also, I have never found an employment situation that was actually superior to the working environment I create for myself. If you arent finding employers that measure up to your standards, or ones that don’t know how to evaluate candidates, perhaps it is a hint that you should be running your own business with a team of peers instead of selling off your future to some company. Why do you want to work for other people when you are smarter than they are?

By: Jacob Santos

Jacob Santos — Wed, 04 Nov 2009 21:39:00 +0000

Well, I think the problem is that the code (wp-cron) has been “fixed” almost every release. The problem is that people have different problems that come up. Lately, I believe you have the ability to just call that page directly using lynx and crontab.

By: Brandon Savage

Brandon Savage — Wed, 04 Nov 2009 20:21:50 +0000

Well, since I’m not on the Wordpress team, I’m not bound to fix their bugs before I work on my own code.

However, in my own projects, and in projects that I do for employment, I always fix code before releasing new code.

By: Joseph Scott

Joseph Scott — Wed, 04 Nov 2009 20:08:25 +0000

Perhaps the “Always” rule for fixing bugs before writing new code isn’t written in stone after all :-)

By: Brandon Savage

Brandon Savage — Wed, 04 Nov 2009 19:59:33 +0000

My patch was to revert to the Wordpress 1.6 cron script. I’ve got six OSS projects of my own (one of the reasons I use Wordpress at all). I don’t have time to fix their buggy software.

By: Joseph Scott

Joseph Scott — Wed, 04 Nov 2009 19:39:09 +0000

Wondering where your patch is with detailed bug report and tests for the wp-cron issue you linked to – http://wordpress.org/support/topic/227742?replies=6

By: Erik Snoeijs

Erik Snoeijs — Wed, 04 Nov 2009 18:52:05 +0000

@Sandy
“best” way for deployment using svn (very much IMHO), is by using svn export. (leaves out all those pesky .svn files)

In a script you can simply export your new release in a shadow directory. Do all the other magic that needs to be done and then

mv live live-04-11-09 && mv shadow live;

By: Brandon Savage

Brandon Savage — Wed, 04 Nov 2009 17:31:38 +0000

That technique does work, but I prefer not to have the hidden .svn files in my document root. While you can have Apache refuse to serve those files, often people do not, and if you’re deploying the code on a client’s server, you probably don’t want to give them access to your subversion repositories.

By: Sandy Smith

Sandy Smith — Wed, 04 Nov 2009 17:28:48 +0000

You can also use “svn switch” and switch from release tag to release tag if you don’t want to treat trunk as the “stable” branch. Or you can have a “production” branch that you merge into and test before deployment. It actually works very well.

By: Ryan

Ryan — Wed, 04 Nov 2009 15:48:13 +0000

The next time I look for a job I’m using your new and improved Joel Test. I’ve tried using the Joel Test in the past, but as you have pointed out, much of the questions didn’t work.

By: Michael

Michael — Wed, 04 Nov 2009 10:56:28 +0000

Great post on Joel Test To Web Development. I have compiled some useful inforamtion on PHP proramming skill set and development platform with some intresting case studies. Hope it makes useful reading for php programmers at http://www.angleritech.com/technology/outsource-php-development.html

By: RobTW

RobTW — Wed, 04 Nov 2009 08:37:46 +0000

Great article. Especially the spec part inspires me a lot.

By: Giorgio Sironi

Giorgio Sironi — Wed, 04 Nov 2009 07:29:42 +0000

Unit testing is becoming fundamental: Unble Bob once said that it’s like double-entry bookkeeping for accountants or washing hands for surgeons. In open source projects like Zend Framework it’s the test suite that allows users to contribute with code and patches.