I find The Joel Test useful and quite easy to apply when I have to figure out what’s wrong in the SW development departments I encounter in my job. When I talk about SW depts I met, I talk about little or mid-sized SW houses (from some working units to many tens of working units), from start-ups to mature IT players, from Industry’s internal ITs to dev teams working for IT consulting companies. I have very little experience of product companies that maintains a SW product with a notable market share.
Here are some considerations coming from my experience; with this article I hope to help you beginning to approach this problem seriously.
The Joel Test
1. Do you use source control?
2. Can you make a build in one step?
This doesn’t mean to click “Build Entire Solution” on your MS Visual Studio Environment; in that meaning it should not be a SW dept process capability, but an IDE feature.
On my PC, for the projects I manage, I can make build in one step with Jenkins either for C# projects or Java projects I work with; conversely, nearly 0% of SW depts I met can say “Yes” to this.
3. Do you make daily builds?
Normally I work by contract, so for a project I can be out of contract for months; so daily builds should be obviously intended for daily running projects. Using Jenkins, I configure it to build every commint to the source control. In this case too, nearly 0% of SW depts I met can say yes.
4. Do you have a bug database?
I have a personal account on FogBugz even for my very personal ultra thin projects. I tried to introduce an issue tracker (such as RedMine) in every SW dept I worked with that didn’t have one; for the SW house I work with almost every day it’s used only on personal or customer attitude basis; it’s not a SW dev process rule. Here I can find more presence of something structured for bugs and requests management.
5. Do you fix bugs before writing new code?
It’s not a strict process rule in SW depts I know, but instinctively it’s at least partially followed.
6. Do you have an up-to-date schedule?
Normally sales depts aren’t able to sell this effort because it’s difficult to make customers understand this value, so contract managers tell PMs to don’t waste time in non-coding operations because they are not paid.
7. Do you have a spec?
Same as number 6, but it’s more frequent to have a spec that an up-to-date schedule. To put me in my expreience exactly in the case six I can ask “Do you have an up-to date spec?”.
8. Do programmers have quiet working conditions?
In my experience I can say definitely No. In the team I haunt overtime it’s considered “normal time” since at least three years. Those who can sometimes go home after their contracted hours are watched as scroungers… These, among other issues such as high bureaucracy levels, are not quiet working conditions.
9. Do you use the best tools money can buy?
Not always. Tools that cost money erode profit in short-term. Almost every contract is short-term so, often, there is not much money in a single contract to buy tools. FLOSS is evil when sales dept talks with customers and is heaven when it’s time to spend money for internal use.
10. Do you have testers?
Sadly I must say no for almost every SW dept I know… Every one is free to test or not his own code. Often, our customers, have dedicated test units to accept SW from suppliers. I write unit tests for my software and let Jenkins report test failures, but it’s so obvious refer again to checks number six and seven…
11. Do new candidates write code during their interview?
Sometimes I have to talk with candidates to join the team I’m working with. New candidates don’t write code during the interview, but they must pass through a “trial period” with objectives adequate to their resume and their future tasks. In this trial period it’s often asked to pass an official certification exam. I think this is a good practice.
12. Do you do hallway usability testing?
This is an interesting method to quickly test software, but I never have the chance to experience it. I wish to!
- A new version of the Joel Test (By Eric Ries 🙂 (startuplessonslearned.com)