The Joel test was written by Joel Spolsky to provide a few very simple questions for developers to ask in an interview. Here they are:
The Joel Test
- 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?
They seem basic, and that's the point: a company with a poor score doesn't give a nice environment to its developers.
While this test is still applicable, it was written in 2000, and software development has seen a lot of changes and innovation. So, I thought of a few other questions that you can ask your current or future employer:
The Geal Test
- Do you use agile development methods?
- Do you have unit tests?
- Do you perform code reviews?
- Do you use known technologies and frameworks (open source or not)?
- Do developers train and learn on office hours, or in their spare time?
- Do developers communicate with system administrators (deployment requests and bug reports don't count)?
- Do developers communicate with the client?
- Do developers retain copyright on the work done in their spare time?
That's it, 8 more questions, 1 point by positive answer. Joel said that 11 or 12 for his test is ok. I'm nicer, so I'll say that 6 on my test is good enough.
1. Do you use agile development methods?
Agile methods have been there for a few years now, and they have proven useful for a lot of projects, especially when you have changing requirements or a very short time to market. Don't let your developers fight everyday against specifications written 5 years ago, let them adapt on the way.
2. Do you have unit tests?
This should be standard. There are a lot of libraries to write tests in every language, for specific functions, for APIs, for user interfaces, so this approach is well supported. Moreover, if you answered "yes" to Joel's question about daily builds, you can add tests to the loop, and run them right after the daily build. If you're not convinced about the usefulness of unit tests, or fear that it will take too much time: unit tests give you assurance that you won't break the code, they can validate the compliance with the specifications, and automated unit tests will save some time for development. You don't want to pay a developer to test manually over and over the same code, but you can buy a machine to do that.
3. Do you perform code reviews?
I know that this one is hard to implement in a team, but once the developers are past the "I'm too shy to show you my code" phase, this will help them spot mistakes, learn from the better developers and find new ways to improve the code.
4. Do you use known technologies and frameworks (open source or not)?
A lot of companies have custom frameworks that they develop and use for their products, that nobody else uses. Although it can be comforting to have your own technology, that you control and maintain, it has a few problems:
- it reeks of NIH syndrome
- it is a cost not directly linked to what you're selling
- you have to train developers to use it
- the expertise they build will be useless in future jobs
If you use known (and hopefully, recent) technologies, you don't have to maintain it (although you may need to pay for it), you profit from bugfixes for other clients, and you are more likely to attract and hire skilled developers. Seriously, I don't want to waste years to maintain your dead framework.
5. Do developers train and learn on office hours, or in their spare time?
Software development moves very fast and a developer needs to catch up often. If you don't allocate time in his schedule to read, try and learn, you can still assume that he will still train himself in his spare time. But you take the risk that your Java developer becomes a Ruby expert, because he will learn what he wants, not what you need. If you want your developers to become experts, help them.
6. Do developers communicate with system administrators (deployment requests and bug reports don't count)?
Too often, the only communication between developers and tech ops is through deployment request and bug reports. The consequence: they don't know each other, they don't trust each other, and when there's a problem, they don't work together. Obviously, this is not a good work environment. As a developer, I'm interested in how my code behaves in real conditions, and I would like helpful bug reports, instead of "it doesn't work, I rollback", and knowing and working with the sys admins can provide it.
7. Do developers communicate with the client?
Ok, this one will horrify some project managers and a few developers. I know that you want to control all the interactions with the client, and that developers sometimes have poor communication skills. But if you put a few layers between the developer and the client, this is what the developer will see: specifications that don't make sense, and useless bug reports. Developers are problem analysis machines, so they can understand the needs of your client, and see right away what is implied in architecture, technology and performance. Use their insight, and they will feel useful, and produce better software. Also, if you can, send a developer to watch a bit how the client works with the software. In 5 minutes, they will spot more bugs and usability problems than in 5 weeks of bug reports.
8. Do developers retain copyright on the work done in their spare time?
When you're passionate about development, you often have ideas, itches to scratch, and you may not be able to develop them at work. But a lot of contracts have non competition clauses and other clauses giving copyright of ALL your work to the employer. As an employer, it's a way to protect the company, but as a developer, it is scary: you can't use or sell the code written in your spare time. Let your developers work on what they want when they're not in the office, and you will profit from the experience they gained developing their side projects (but state clearly that they work for you on office hours).
Bonus
I also have 4 bonus questions. They're optional, but they don't hurt.
- Do the developers participate in <LANGUAGE> user groups or developer meetups? In these meetups, they will learn a lot, and if they're experts and enjoy working for you, they will attract other developers.
- Will I have a technical manager? It is reassuring for a developer to know that his manager has a clue about development, knows the difference between a good and a bad developer, can understand his problems and stabd up for his team.
- Do you use a recent version control software? Joel already asked this, but it needs to be precised. Version control systems have improved a lot since his test so, if you can, avoid old stuff like CVS or (worse) SourceSafe. Subversion is fine for most setups now (even on Windows), and if you use Git or Mercurial, I will be reaaaally happy.
- Do you accept remote working? There are a lot of tools to communicate online: mail, IM, VoIP, web project managers and bug trackers, and developers often know very well how to use them. It's comforting for the employer to know that the developer is always at arm's length, but this will not mean they're more productive. If you remove distractions from the work environment (phone, colleagues), the developer can be more productive (yes, there are actually LESS distractions at home). Also, they won't waste time in transport.
Now, if you're a developer, rate your own company or future job. If you're a manager, rate your team, and please, please, on behalf of all the developers out there, try to get the perfect score!
How much did you get?