63

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?

Improve this question

8 Answers 8

Reset to default
49

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?

Improve this answer
3
  • Isn't your #6 identical to #8 on the Joel test:
    – HerbN
    Sep 11, 2010 at 5:53
  • It's Jeff Atwood's #6, and yes, it is.
    – spong
    Sep 11, 2010 at 10:41
  • It looks like the Joel Test is more specific to helping programmers develop clean, bug free software as opposed to working conditions, except #8
    – Archmede
    Apr 18, 2019 at 17:29
14

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.

Improve this answer
10
  • 15
    The problem with bouncing ideas off teammates is that ASKING them verbally is a huge distraction. If you need to do some serious collaboration, then work in a collaboration space. But for "hey how would you do this" questions you're much better off with IM.
    – Matt Olenik
    Sep 15, 2010 at 23:13
  • 4
    You can't ever mean eight people in the same room, can you? I'm already annoyed by sharing a room with three other programmers (each of which works on his own stuff, with one working on a completely not related project and another one being the backend/database guy). I know for sure that if I shared the room with seven other guys I'd just go postal.
    – Baelnorn
    Sep 29, 2010 at 2:57
  • 3
    @ChrisF: perhaps that's the problem. The four of us sitting in the same room barely have anything to do with each other, programming wise. It's more like 4 people working on 2 1/2 projects sitting in the same room. And now add a boss who absolutely doesn't mind holding half-hour long discussions with another programmer right next to your desk despite the meeting room being just across the hallway. >.<
    – Baelnorn
    Sep 29, 2010 at 21:51
  • 3
    @ChrisF - "Writing software in the real world is a team activity, you need to talk to your team-mates to bounce ideas around etc. and that is so much harder with people in separate offices." - So, how do development teams spread across different locations work? I've worked closely with people across the US or Brazil or India - IM and Adobe Connect - as well as co-located, from small to very large distributed teams. Yours is a very disruptive environment. Working in teams can be done efficiently, but what you are prescribing is anything but (your idea is right from waterfalling the 70's)
    – luis.espinal
    Oct 15, 2010 at 11:54
  • 1
    @ChrisF - could be. I mean, every person has different (and legitimate) work experiences. I rather have people IM me than walking over to my desk and disrupt my line of though when coding. It forces communication to be very concise, spartan and to the point. Anything that requires more complex communication, e-mail. Anything truly urgent, a face-to-face meetup (or a call or teleconference for those in remote locations.) From waterfall to very agile, I've found that companies that do this help programmers retain their focus during development, reducing the signal-to-noise ratio.
    – luis.espinal
    Oct 15, 2010 at 12:03
13

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.

Improve this answer
11

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?
Improve this answer
4
  • 27
    I think you'd be surprised how many companies can't make a build in one step and don't have a bug database. You're probably right about source control, but I'd argue that a lot of companies use it simply to backup their code and don't even scratch the surface of the benefits of source control.
    – Rob Sobers
    Sep 17, 2010 at 2:38
  • 1
    When I started at my current job we had a source control system, but builds were done on one guy's machine and only he knew all the steps, and bugs were tracked on paper. These are all "fixed" now, but I'd never take these things for granted.
    – Arjailer
    Jan 11, 2011 at 17:23
  • 1
    Just look at the job postings on SO. The number of them that fail the first three is surprising.
    – Django Reinhardt
    May 27, 2020 at 12:54
  • @DjangoReinhardt I'd forgotten about these questions. They used to appear as a tick list on SO job postings. Not seen any of those for years. It's not like job ads have much in the way of information for those that might be interested.
    – Tom Hawtin - tackline
    May 27, 2020 at 13:52
7

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.

Improve this answer
2
  • 1
    Isn't 3 already in the list?
    – Casebash
    Sep 12, 2010 at 0:57
  • Yes, in one form or another it is. But I list mine a bit differently so I left it there.
    – Mitchel Sellers
    Sep 12, 2010 at 8:06
5

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.

Improve this answer
3
  • 2
    Surely its a cultural thing - if its not excessively disruptive and if its a part of the way the business functions then it shouldn't "tick people off" - especially not if the purpose of the business is development of applications.
    – Murph
    Sep 14, 2010 at 10:03
  • 1
    Maybe the point is it should be a part of other people's job?
    – JeffO
    Sep 15, 2010 at 20:58
  • 9
    the whole point of hallway usability testing is that it needs to be someone who doesn't use the program regularly. Once you've built it and/or spent hours using it (like a dedicated tester) your perspective on the app is going to be skewed
    – GSto
    Sep 15, 2010 at 21:38
5

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.

Improve this answer
5
  • 14
    You're missing the point. The Joel Test isn't about how good the software is, it's about how effective the production process is. A team that fails the Joel test may still make good products, but chances are it'll take much longer and the workers will be miserable. Also, tools doesn't refer just to software. It also means hardware, from your computer down to your desk and keyboard.
    – Matt Olenik
    Sep 15, 2010 at 21:34
  • I think you're missing the point. If a team finishes projects on time and produces good quality software, they are, by definition, effective. And they have, by definition, an effective process.
    – GrandmasterB
    Sep 15, 2010 at 22:05
  • 2
    You never mentioned shipping on time. Also, I'd be extremely surprised to see an effective team that failed (completely) the Joel Test. Things like version control, testing and usability are all critical. The other items can be pretty big impediments as well.
    – Matt Olenik
    Sep 15, 2010 at 23:11
  • This is a good point, but the main weakness is the subjectivity of it. Everyone might have a different opinion of the software quality, depending on their experience, skill level, and usage perspective. But I do like the point.
    – Bernard Dy
    Dec 18, 2010 at 14:15
  • If their effective process is only effective for the members that are on the team, particularly if the team is small, how well will it stand up to growth or in the event of an untimely disaster or retirement? Being able to produce code that works well and ships on time via a process that just exists in the heads of the people developing it is a recipe for disaster, a team that sooner or later (probably sooner) will face an issue from which most people can't, or simply won't want to, recover.
    – Finni McFinger
    Sep 12, 2016 at 21:20
5

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).

Improve this answer
3
  • Agreed. Once you move away from the "top of the stack" apps, a lot of contemporary ideas seem to become a bit... irrelevant.
    – Paul Nathan
    Sep 29, 2010 at 22:04
  • I agree. There are a lot of developer jobs in corporate IT shops...certainly not as glamorous as doing shrink wrap. As most of these companies are not in the software business, most of them typically score about 4 on the Joel Test.
    – Bernard Dy
    Dec 18, 2010 at 14:21
  • 7
    Why wouldn't you create unit tests for embedded software (and have them automatically run by a build system)?
    – Peter Mortensen
    Oct 28, 2013 at 16:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.