I just learned about the Joel Test. I have been computer programmer for 22 years, but somehow I never heard about it before. I consider my best job so far to be this small investment managing company with 30 employees and only three people in the IT department.
I am no longer with them, but I had being working there for five years – my longest streak with any given company. To my surprise they scored extremely poor on the Joel Test. The only two questions I would answer “yes” are #4: Do you have a bug database? And #9: Do you use the best tools money can buy? Everything else is either “sometimes” or straight “no”.
Here is what I liked about the company however:
-
Good pay. They bragged about it to my face, and I bragged about it to their face, so it was almost like a family environment.
-
I always knew the big picture. When writing code to solve a particular problem there were no ambiguity about the business nature of that problem. Even though we did not always had written specifications we could ask business users a question anytime, often yelling it across the floor. I could even talk to executives any time I felt like doing it: no appointment necessary.
-
Immediate feedback. Once we implement a solution and make business users happy they immediately let us know that, we (programmers) become heroes of the moment.
-
No red tape. I could always buy any tools I deemed necessary, and design solutions the way my professional judgment dictates.
-
Flexibility. If I had mid-day dental appointment that is near my house rather than near the office, I would send email to the company: “FYI: I work from home today”. As long as one of three IT guys was on the floor (to help traders in case their monitors go dark) they did not care where two others were.
So the question thus becomes: How valuable is the Joel Test? Why bother with it?
7
I think it’s important to keep in mind what the Joel test is for.
I don’t think it in any way measures working conditions at a company. I don’t think it was ever meant to do that. Your question seems to imply that this is what it gauges.
Joel claims this is a test is to
come up with my own, highly irresponsible, sloppy test to rate the
quality of a software team.
Personally, while I believe everything on that list is important, I don’t believe it is an accurate measure of how “good” a team is. Nothing is going to replace smart people with a solid work ethic.
If you have a team of smart people with a solid work ethic with a 0 on the Joel test, it will outperform a team of lazy idiots with a perfect score on the Joel Test any day of the week.
That being said, a team of smart people with a solid work ethic will likely implement at least some of the things on the Joel test.
4
The Joel Test has nothing to do if you can have a comfortable position in a company. And #9: Yes, it is a sign that you can where you are.
It’s about professional software development. In a very small IT with a small codebase that everybody knows very well, not all of the points are as important from my opinion, but 1-3 are:
1) Do you use source control?
This is essential. Set up a Git or Subversion repository immediately to have the possibility to check changes made since the last release to identify a buggy change or retest a report on a non-actual version.
2) Can you make a build in one step?
Build (and test everything) should be as easy as possible to force the developers to do it often!
3) Do you make daily builds?
A continious integration server is set up easily (like Jenkins, CruiseControl or a professional one like Bamboo or TeamCity) and ensures every change will be tested automatically and every developer gets informed about failures. 1. and 2. are prerequisites for this one!
The other point become more important the more developers are working on the code and the more complex the software becomes. For some of them there are work arounds (headphones for 8. for example.), but all of them will make a software company become more professional I think.
So think about it, and see if some of them make sense for you and which of them you can start by yourself. Point 1. to 3. should be possible and the preconditions can be done by one developer on a single day.
Keep in mind that Joel’s perspective is from within a software company (Microsoft, Stackoverflow). The idea behind the test is that a company should be, or strive to be, competent when working within their primary field.
From your description, it sounds like software was not the primary business of your company. If you described the company as an “Enterprise investment software provider” with 30 developers instead of 3, the test might be a better indicator of competency.
Additionally, if you applied the concepts behind the test to their primary business, they would probably have a decent score: Do they have a way to track the history of investments made? Can they make a transaction in as few steps as possible? do they have a spec/algorithm/process for investments? etc…
1
I can’t stand Joel test because it requires you to give a simple yes or no answer. Below I’ll give few examples on how this test completely fails in my eyes.
Do you use source control?
- A1: Yes
- A2: Yes, I do a check in once a week and I don’t have any kind of version control strategy.
Do you have a spec?
- A1: Yes
- A2: Yes, it’s written on a bit of A4 paper somewhere on my desk.
Do you have testers?
- A1: Yes
- A2: Yes, we have two testers and 20 developers.
Do new candidates write code during their interview?
- A1: Yes
- A2: Yes, we ask them to write FizzBuzz app
My point is, that if somebody simply gives you a ‘Yes’/’No’ answer, than it won’t tell you anything about their company. I personally get put off the company as soon as Joel’s test gets mentioned.
3