In 2000, Joel Spolsky published 12 simple questions to measure the maturity of a software team. A quarter century later, this test remains one of the most effective diagnostic tools in the industry.
In August 2000, Joel Spolsky, co-founder of Fog Creek Software and creator of Trello, published on his blog "Joel on Software" an article that would become a reference: The Joel Test. The premise: 12 binary yes/no questions that let you evaluate the quality of a development team in two minutes. Perfect score: 12. Acceptable: 11. Below 10: serious problem.
What makes this test remarkable is its durability. Twenty-five years later, the core still holds — even if some questions deserve updating in light of modern practices.
The 12 questions
1. Do you use source control?
Today the question would be: do you use Git with a branching strategy? A team without version control in 2024 is a curiosity. But the underlying question remains valid: are your versioning practices consistent and shared across the team?
2. Can you make a build in one step?
A complete build — compilation, tests, packaging, deployment — must be triggerable by a single command or click. If this step requires a ten-item manual checklist, errors will inevitably creep in. This is the foundation of any serious CI/CD pipeline.
3. Do you make daily builds?
In Spolsky's logic, a broken build stops the team. The rule: if a build is broken at end of day, whoever broke it fixes it before leaving. With modern continuous integration, the question becomes: do your CI pipelines run on every commit, and are they taken seriously when they fail?
4. Do you have a bug database?
No bugs in a spreadsheet, no bugs in people's heads, no bugs in a Slack thread: a dedicated, searchable database with status, priority, and reproducibility. Linear, Jira, GitHub Issues — the tool doesn't matter. The absence of a tool does.
5. Do you fix bugs before writing new code?
The classic trap: accumulating a backlog of unresolved bugs to "ship features". Every unresolved bug is a permanent cognitive load on the team, a regression risk, and a signal sent to users. The best teams address critical bugs immediately.
6. Do you have an up-to-date schedule?
A schedule doesn't serve to predict the future with precision — that's impossible. It serves to force conversations about priorities, to detect dependencies, and to align expectations with stakeholders. A team without a schedule (or with one that is systematically ignored) is a team that reacts rather than leads.
7. Do you have a spec?
This isn't a question about exhaustive documentation. It's a question about thinking. Writing a spec — even a short one — forces anticipation of edge cases, resolution of ambiguities, and alignment between developers and product owners before code is written. Correcting a spec costs nothing. Correcting production code costs a lot.
8. Do programmers have quiet working conditions?
Interruptions are the enemy of concentration. A developer interrupted every ten minutes cannot enter the flow state needed for complex work. This concerns workspace layout, interruption culture, and meeting management. A calendar fragmented into 30-minute slots is a productivity-destruction machine.
9. Do you use the best tools money can buy?
The best developers are those who master their tools. A slow IDE, an underpowered laptop, unstable development environments: these are daily frictions that accumulate. Skimping on a development team's tooling is a false economy.
10. Do you have testers?
Spolsky is categorical: if you think developers can test their own code as well as a dedicated tester, you are wrong. The brain that wrote the code is poorly positioned to find its own blind spots. Automated tests do not replace human exploratory testing — they complement each other.
11. Do new candidates write code during their interview?
An interview without a practical exercise reveals nothing about coding ability. An impressive CV doesn't say whether the person can decompose a problem, write clean code under constraint, or explain their choices. This question remains one of the most important in the test.
12. Do you do hallway usability testing?
The idea is simple: take someone who hasn't worked on the product, show them a feature for five minutes, and observe. You will discover UX issues in minutes that months of development had obscured. Five untrained testers reveal 85% of usability problems according to Nielsen's research.
How to interpret your score
| Score | Interpretation |
|---|---|
| 12 / 12 | Mature team, solid practices |
| 11 / 12 | Very good level, one point to address |
| 9 – 10 / 12 | Significant gaps to correct |
| < 9 / 12 | Structural problems, high organisational debt |
The test does not measure code quality or individual talent — it measures the collective practices that allow a team to consistently produce quality software. A brilliant team with poor practices produces, on average, less than an ordinary team with good practices.
What the test doesn't cover
Spolsky himself acknowledged the limitations of his test. In 2000, he hadn't anticipated:
- Continuous deployment (CD) and infrastructure as code
- Security practices (SAST, security reviews, dependency management)
- Feedback culture: retrospectives, one-on-ones, blameless post-mortems
- Technical debt and its explicit management
- Distributed team work and its specific challenges
More recent frameworks like DORA metrics or the SPACE framework usefully complement this grid.
Gotan and team assessment
At Gotan, we use the Joel Test — enriched with additional questions — as a starting point in our team diagnostics. It quickly opens honest conversations about actual practices versus stated ones.
What consistently emerges: the teams that progress fastest are not those who score 12/12 from the start. They are the teams that clearly identify their gaps and methodically address the two or three points most blocking their collective effectiveness.