What do you think about the Joel Test? [closed]

Question

The Joel Test is a well known test for determining how good your team is. What do you think about the points? Do you disagree with any of them? Is there anything that you would add?

Answer 1

Jeff Atwood has The Programmer's Bill of Rights.

From the post:

1. Every programmer shall have two monitors
2. Every programmer shall have a fast PC
3. Every programmer shall have their choice of mouse and keyboard
4. Every programmer shall have a comfortable chair
5. Every programmer shall have a fast internet connection
6. Every programmer shall have quiet working conditions

This seems to have some items that I'd like to see on Joel's list. Specifically in the area of hardware (dual monitor, fast PC, mouse/keyboard, comfortable chair, fast connection).

The only thing not mentioned is having a comfortable and adjustable desk.

This could all be added by changing:

Current #9: Do you use the best tools money can buy?

to

Improved #9: Do you use the best tools and equipment money can buy?

Answer 2

It's interesting that point 8 now reads:

8. Do programmers have quiet working conditions?

when it used to read (something like)

8. Do programmers have their own office?

and the last paragraph still starts:

Now let's move them into separate offices with walls and doors.

I was always suspicious of this test as in all the places I've worked - both as employee and visitor - the only people with their own offices are the directors and senior managers.

Writing software in the real world is usually a team activity, you need to talk to your team-mates to bounce ideas around etc. and that is harder to do with people in separate offices even with instant messaging systems. Being able to draw things out and show people code and diagrams helps a great deal. This isn't to say that distributed teams can't work - they obviously can and do, that's just a different set of problems.

What I would say is that each team needs to be in it's own office of 6-8 people (assuming that's the size of the team). That way they can interact without disturbing the other teams (if there are any) and get on with their work without being disturbed by the sales team or visitors (at one place I worked you came through the front door straight into the development area).

If you are working with other developers, but each is working on separate projects, then a shared office can be useful - but only if you are strict about taking meetings to the meeting room and respecting other people's deadlines etc.

Most of the others are self evident truths.

Answer 3

I like it but if I were using it to evaluate a company I wouldn't equally weigh all the items. Not having source control is a much bigger problem then not buying the best tools money can buy.

Answer 4

The only deal-breaker for me is:

 8. Do programmers have quiet working conditions?

Interesting it's the question most likely to be failed by Stack Overflow job postings.

Some of the questions are difficult to fail, particularly if there is more than one programmer in the company:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

Most of the others I don't really care about. I mean, honestly:

12. Do you do hallway usability testing?

There is one to detect liars:

 5. Do you fix bugs before writing new code?

Answer 5

I have to say that it is a good "baseline", but with any measuring tool there are other factors. For example not a single company that I have worked for has done Daily Builds (I know, I know), but some of them have been very good.

I personally have a few other items that I would add to a list.

1. Do you support developer education by attending conferences, purchasing books, or something of that nature?
2. Do you have a simple, documented process to adopt new tools if necessary to complete job functions
3. Do you provide developers equipment and an environment that will allow them to be productive.

More than anything these are items have have "pissed me off" from previous employers, and well they are now fast track questions that I ask about each and every opportunity.

Answer 6

I agree with most of Joel's points. I'm not so sure about "hallway usability testing". Usability testing, sure, but actually grabbing someone from the hallway and making them test your program, even though it's not their job? That seems like a great way to tick people off.

Answer 7

Although I think it makes good sense in the general sense, I found the list quite centered on the specific kind of software that Fog Creek Software does (shrinkwrap). That's not really surprising, as he also talks about that on another post, Five Worlds. And there are lots of developments outside that world.

There are some conditions that really don't make a lot of sense if you develop for example embedded software for a satellite or a vending machine, like daily builds (3) or usability testings (12).

Answer 8

The Joel Test does not test how good a team is. It tests how well your team adheres to the Joel Test.

Here's a better test of how good your team is. I call it the GrandmasterB test. It has one question.

1) Is the software you write any good?

It's irrelevant to me whether you 'hallway test' or not, or what source control you have, or what your build process is (if there is one - not every lanugage has them). The true measure of a team is the quality of the software they create.

Basically, you could follow every single step of the Joel Test, and still end up with crap code and products that never ship. For example, source control does not magically make one a better coder; it makes code easier to manage. And having the latest version of Visual Studio doesn't mean your application will work better than if it was written with Visual Studio 2005.