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?

Casebash
  • 7,662
  • 5
  • 41
  • 62

8 Answers8

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?

spong
  • 9,361
  • 6
  • 44
  • 58
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.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • 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 '10 at 23:13
  • @Matt - For the little things you're right, but office space is always scarce - no company wants to spend money on empty offices - which is why having teams in their own space helps. You can turn the office into a "collaboration space". – ChrisF Sep 16 '10 at 07:39
  • I've found three is the ideal number in an office. Eight people in an office, talking to someone disturbs six people. (I don't work with anyone in the same country as me, yet I'm in an open plan office. :() – Tom Hawtin - tackline Sep 20 '10 at 17:12
  • 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 '10 at 02:57
  • @Baelnorn - I don't know where you work, but the only time there were less than 6 people in the same room was when I worked for company that consisted of 6! However, I've always worked as part of a team. – ChrisF Sep 29 '10 at 08:14
  • 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 '10 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 '10 at 11:54
  • @luis - maybe it's just me then. – ChrisF Oct 15 '10 at 11:57
  • 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 '10 at 12:03
  • +1 for colocation. Close communication between team members is vital, and becomes much more difficult when people are in different rooms, buildings, countries, timezones etc. – Armand Nov 29 '10 at 23:01
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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
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?
Tom Hawtin - tackline
  • 662
  • 4
  • 12
  • 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 '10 at 02: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 '11 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 '20 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 '20 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.

Mitchel Sellers
  • 651
  • 3
  • 4
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.

Tim Goodman
  • 2,644
  • 2
  • 28
  • 25
  • 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 '10 at 10:03
  • 1
    Maybe the point is it should be a part of other people's job? – JeffO Sep 15 '10 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 '10 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.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
  • 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 '10 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 '10 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 '10 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 '10 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 '16 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).

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Khelben
  • 1,339
  • 1
  • 8
  • 8
  • 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 '10 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 '10 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 '13 at 16:04