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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as not constructive by MichaelT, Kilian Foth, thorsten müller, Bart van Ingen Schenau, Jalayn Apr 17 '13 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 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, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
Jeff Atwood has The Programmer's Bill of Rights.
From the post:
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?
Improved #9: Do you use the best tools and equipment money can buy?
It's interesting that point 8 now reads:
when it used to read (something like)
and the last paragraph still starts:
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.
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.
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.
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.
The only deal-breaker for me is:
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:
Most of the others I don't really care about. I mean, honestly:
There is one to detect liars:
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.
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).
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.