The Monty Test - A revised Joel Test

12 years ago, Joel Spolsky, Founder of Fog Creek Software developed the so called Joel Test.

The purpose of these 12 questions is a test, if a company is able to create quality software. 12 years is a long time and as a Software Craftsman I dont’ agree with all of these questions anymore. So here is an updated proposal:

So here are my thougths on this topic in a more detailed form:

1. Do you use (distributed) source control?

The original question was “Do you use source control?”. In 2012 this should be no question anymore. Teams without source control are simply not professional software developers. So the question was extended to “Do you use a DVCS?”. This should be a bonus point, as SVN should suffice too. If you see CVS, run…

2. Can you deploy your software in one step?

The original question was “Can you make a build in one step?”. The question targets Continuous Integration systems. This should be extended to Continuous Deployment nowadays. This step also implies also having automatic acceptance tests (see also question 7).

3. Do you build on every commit?

The original question “Do you make daily builds?” is a bit outdated. Builds should be made by your CI system on EVERY.SINGLE.COMMIT. Period.

4. Do you have a bug tracker which is connected to your source control system?

Here it is the same as with question 1. The original question “Do you have a bug database?” doesn’t suffice anymore. The Bugtracker you use should be able to communicate with your source control system and with other tools like code review systems to easily update bug states on commits and reviews.

5. Do you fix bugs before writing new code?

This is still up to date and should remain so. But this should be supported by short release cycles, TDD and continuous fearleass refactoring.

6. Do you have short release cycles?

The original question was here “Do you have an up-to-date schedule?”. I think this should be extended to “Do you use agile techniques like SCRUM?” or in a more generic form “Do you have short release cycles?”, as this takes this problem away from the programmer and moves it to a project manager. The point is here more to have a continuous communication about the schedule (and what can be achieved within this schedule) with the stakeholder.

7. Do you have a runnable spec?

The original question “Do you have a spec?” doesn’t suffice for me. The specs in the form of user stories and epics should be executable through a tool like Cucumber or Fitnesse. The specs should be the acceptance tests too.

8. Can your developers work easily together?

With the original question “Do programmers have quiet working conditions?” I cannot agree at least not with the description Joel Spolsky gives. He writes that a developer is most productive if he is in “the flow” (or “the zone” if you like it better). I tend here to agree with Uncle Bob in his book The Clean Coder, where he says that being in the flow can be productive for “boring” repeated work but dangerous for productive high quality programming where we need all our focus on the current topic. In my opinion it is better to have a work environment, where developers can easily communicate and collaborate. That doesn’t mean a big room stuffed with cubicles or worse none at all, but small interconnected and easily accessable rooms with round tables where up to 4 developers can sit around and work together.

It gives a bonus point, if in the company a culture of pair programming is practiced.

9. Do you use the best tools money can buy?

Here I agree with the author. The developer should have access to the best tools available, no matter of the cost. But this doesn’t mean, the more expensive the better. Luckily some of the best tools available are free, so they should be used. The point is to have the best tools needed to do the job.

So if the developer asks for a specific tool for some task, then give it to him. Finally he is the one who has to work with it.

10. Do you have full time testers?

We as professional developers write unit tests. And we practice TDD. The main slogan should be “QA should find nothing”. But this doesn’t mean, that we don’t need manual tests. These tests should be simply reduced to a minimum and used for issues which cannot automated (e.g. spell checking on ad pictures etc.). And these tasks should not be done by the developers but by professional dedicated testers. So I extended the original question “Do you have testers?” to “Do you have full time testers”.

11. Do new candidates write code during their interview?

Here I agree with the original author too. How can you decide if the candidate you interview is a good developer, if you have never seen a single line of code from him?

Most professional developers maintain or contribute to open source projects, so the employer can look for work probes in advance of the interview, but he should demand some live coding samples anyway during the interview.

12. Do you do usability testing with end users?

Here was some improvements in the last 12 years. Since professional development companies use agile methods to develop its products, there are continuous reviews by the stakeholders at the end of a short release cycle. Unfortunately the stakeholders are in the most cases no end users. So this question is as up to date as ever.

This article was written by Martin Gondermann on 2012-12-04 in Software Craftsmanship .

Categories

Github repositories

Links