Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 19 down vote favorite
4

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?

share|improve this question

closed as not constructive by MichaelT, Kilian Foth, thorsten müller, Bart van Ingen Schenau, Jalayn Apr 17 at 12:39

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

8 Answers

up vote 14 down vote accepted

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?

share|improve this answer
Isn't your #6 identical to #8 on the Joel test: – HerbN Sep 11 '10 at 5:53
It's Jeff Atwood's #6, and yes, it is. – sunpech Sep 11 '10 at 10:41
up vote 10 down vote

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

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.

share|improve this answer
2  
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 7: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
1  
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 2:57
1  
@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
show 5 more comments
up vote 6 down vote

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.

share|improve this answer
up vote 4 down vote

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.

share|improve this answer
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
Maybe the point is it should be a part of other people's job? – JeffO Sep 15 '10 at 20:58
1  
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
up vote 4 down vote

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.

share|improve this answer
Isn't 3 already in the list? – Casebash Sep 12 '10 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 '10 at 8:06
up vote 4 down vote

Although I think it makes quite sense in general sense, I found the list quite centered on the specific kind of software that Fog Creek does (Shrinkwrap). That's not really surprising, as he also talks about that on another post. 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).

share|improve this answer
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
up vote 3 down vote

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?
share|improve this answer
5  
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 2:38
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. – HappyCat Jan 11 '11 at 17:23
up vote 2 down vote

The Joel Test does not test how good a team is. It tests how 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?

Its 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 Visual Studio doesnt mean your app will work better than if it was written with VS2005.

share|improve this answer
2  
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
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

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