The Joel Test is a great way to quickly test a software development team’s performance, even if you are the only developer. I’ve been the sole developer for Little Stream Software for over a year now, so I think it’s a good time to rate how I’ve changed since my “programmer as a cog in the machine” days.
1. Do you use source control?
Yes. In fact I’m advocating using good (Subversion) and great (Git) source control systems to my customers.
2. Can you make a build in one step?
This would depend on the project. The majority of the Ruby on Rails projects are built/deployed in one step but most of my PHP projects take several steps. The biggest hurdle is that several of my customers don’t see much benefit from automation, which is a failure to educate on my part. I know one project where I spent a considerable amount of time automating the testing and database changes (think rake db:migrate) and now it’s used by all the developers and on the production systems. Easily hours of time saved with no errors.
Overall though, I would say no I cannot make a build in one step.
3. Do you make daily builds?
Since Ruby and PHP don’t need “builds”, I’m considering builds to be a fresh checkout and smoke test of the application. I used to use CrusieControl.rb to run smoke tests but I’ve neglected it for awhile. No, I don’t make daily builds.
4. Do you have a bug database?
Yes, Redmine is perfect for that.
5. Do you fix bugs before writing new code?
It depends on the customer. Some customers acknowledge a bug’s existence but they decide it isn’t worth fixing. So I get a yes for effort and a “sometimes” in practice.
6. Do you have an up-to-date schedule?
Yes, on every project I set a deadline even if my customer doesn’t have one. This constrains me and lets me focus on getting the work done.
7. Do you have a spec?
Yes, I create a minimal spec for every project. Sometimes it’s vague; when the customer isn’t sure what they want and need flexibility. Sometimes it’s very detailed; when it’s creating a public API, major integration point, or requires a fixed priced and fixed scope bid.
8. Do programmers have quiet working conditions?
Yes, since I work from home I can control the amount of noise where I work. I tried to work in a coffee shop but it’s way to loud for me to get into the zone.
I’d really like to watch a programmer who in a coffee shop and see how much work they actually get done.
9. Do you use the best tools money can buy?
This is a tough question. For me a tool needs to be useful and the user needs to be knowledgeable enough to use it to it’s full potential. Eclipse is a wonderful tool for many people but in my hands it’s just a pretty text editor because I don’t have the knowledge to take advantage of it.
If I have the choice, I use the best tools available to me (Ruby on Rails, git, Emacs, Linux, Rake) but some projects require worse tools. These tools are not inherently worse but in my hands they don’t help me as much as my best tools.
Yes, I use the best tools I have access to and try to increase my knowledge of them frequently.
10. Do you have testers?
No, since I’m the only person I don’t have testers. I’ve checked out a few freelance testers but most of them only caught obvious bugs and I didn’t see much value from them.
11. Do new candidates write code during their interview?
Yes, if I hired anyone I would require them to write code or provide examples of their work.
12. Do you do hallway usability testing?
Yes, when I’m working on a team with other developers I try to make them use my code. I especially use this on integration points and I’ve had some great results so far.
Summary
So I scored 9 points out of 12 (1, 4, 5, 6, 7, 8, 9, 11, 12) which means I have “serious problems” according to Joel. I don’t agree with the summary because my “team” is only me but I do see a lot of room for improvement. I can increase my performance by adding some more automation to my work, specifically:
- Create build files to build and deploy a project in one step.
- Fix CrusieControl.rb and add all my projects to it.
So how am I doing compared to the “programmer as a cog in the machine” days? Lets just say they would be happy to get 9 points.
Eric
Hello,
In point 5 “work fixing” should be “worth fixing”
I think some of the points don’t apply well to your situation(mostly building), because you’re using dynamic languages, so your average is higher
how can someone be talking about builds when scripting langauges are the subject of discussion ?
joel is crap
“Build” is not synonymous with “compile.” You can still “build” dynamic language projects, web projects, etc. What Joel means by build is “Can you produce the final output of your project, ready for deployment, in one step.” For compiled code this would be a compilation, perhaps running unit tests, and packing it into some sort of installer. For dynamic projects this may just be packing it into some installer or tarball. For web projects this would be placing all of the required files into the required structure as they would appear in your virtual directory.
The purpose of this “rule” in the Joel test is to minimize the amount of human interaction required to produce what you deliver to clients / production environments. If deploying changes to your website involves 9 steps that only one guy in the company knows there’s a lot more opportunity for screw ups than with a single automated process.
Soufi: Thanks, I’ve corrected my typo.
Lucas: You are right about dynamic languages not needing a proper “build” but they still need to meet a base standard. With C, the compiler will break if you had syntax errors. With dynamic languages, you don’t have a compiler to check for these so a basic smoke test is required. Running the interpreter on every code file is a start (@ruby -c foo.rb@) but unit tests actually help to make sure the code actually does what it’s supposed to.
Someone: Joel wasn’t taking about scripting languages at all, he was talking about programming in general. For an article over 8 years old, he’s still *really* correct. (and sadly there are still many companies not even scoring 2 or 3 on it)
Anon: Good job pointing out the assumption that “build” == “compile”. Automation is key to producing “builds”, in fact I’m thinking about setting up a build server so it will push successful changes out to a staging server automatically. That way a project is releasable (and released) every step along the way.