Does Anvil pass the Joel Test?
Ever heard of the Joel Test?
It's a simple test to measure how well a software team performs. It takes less than 3 minutes to complete, because its a simple yes/no answer test to twelve questions:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
So for fun, I thought I would take the test.
Do you use source control?
Yes. Anvil's source code is maintained in a Subversion source code repository. Some of my previous posts included screencasts where you see Subversion in action (indrectly).
Can you make a build in one step?
Yes. We use Automated Build Studio. I blogged about that earlier today.
Do you make daily builds?
Yes. See above.
Do you have a bug database?
Yes. We use FogBugz. I blogged about how we track defects earlier this month.
Do you fix bugs before writing new code?
Yes. Although everything is new code right now. :)
Do you have an up-to-date schedule?
Yes. I use a mindmap to track requirements and project plans. I blogged a bit about how I use mindmapping for project planning.
Do you have a spec?
Yes. Sort of. Although we don't use spec docs like Joel defines it, I screencasted how we use functionality mindmaps , technology mindmaps and threat models.
Do programmers have quiet working conditions?
Yep. I telecommute quite a bit myself and use a lot of quiet space in my home, including a full home office. Most of Anvil was written on my back deck this summer, while I listened to the rustling leaves of the huge trees in my backyard in British Columbia, Canada.
Do you use the best tools money can buy?
Yes, I believe so. There is a list on the right side of this blog.
Do you have testers?
Yes. And we use automated functionality testing with the use of TestComplete.
Do new candidates write code during their interview?
Yes. Although I didn't hire anyone for this project yet. Remember... it was supposed to be just me.
Do you do hallway usability testing?
Yes. Although to be honest I don't pick people out of the hall. Two days ago I had the gardener try the Anvil Manager. Yesterday I had my wife try it. Today it was a potential customer. I will have a few more people check it out before I ship a public beta.
So there you have it. Looks like I pass the Joel Test with an A+. If you work with software in your business, take the test yourself and see how you do. And make sure you read Joel's article on the subject.
Comments
We also pass the Joel Test in most points, and where we do not, we know we should, except for daily builds--I have not read any convincing arguments yet, at least for shrink-wrapped software.
If you have a few spare minutes, can you please tell me why you decided to make daily builds for Anvil?
Posted by: pb | September 1, 2006 12:35 AM
Sure pb.
We always fix code before writing new code. Each time a fix has passed the automated tests it is allowed to be checked in to the source code repo, making it available for a newer build.
The testers can then use the new build for their testing. It doesn't make a lot of sense to test an older build which may have particular bugs fixed already. It's a waste of time to follow a bug that is already fixed!
Daily builds also give us an assurance that the product is ready to go at any given time. Our goal is to ALWAYS have a "shippable" product. Each day new features are completed the daily build is done to ensure the new features don't break compatibility with the existing product. This ensures we don't spin too far out of control and break the build.
Many days, the daily build ends up being identical as the day before. No biggy. No one is harmed by it. But when bug fixes and new features are available for testing, we want to make sure we get it in the hands of those that can test it.
Posted by: Dana Epp | September 1, 2006 09:00 AM
Thanks Dana. We use a bit different processes that might have made daily builds less useful for us until recently.
Our project is kind of a micro ISV in a small ISV, only 1 dev (now 2, which is going to change processes) and 1 tech support guy.
In the current process, new code modules are developed in stand-alone test projects, get tested, integrated and tested again by the dev before check-in. We do not have in-house testers, but we release builds with larger changes or bugfixes to a few users in our test program. We always release immediately when such build is ready to be made.
The point is, we do not wait for the daily build, but build immediately.
Now with the new dev, we need to change this, because we have to be able to release even if the one of the devs is out of the office; code must be always in consistent state.
Posted by: Peter | September 1, 2006 10:58 PM