Published
- 7 min read
The Joel Test - 12 Steps to better Code
The 12 questions of the “Good Development Workflow Test” are a set of yes/no questions that help determine the quality of a development workflow. A score of 10 or lower suggests that there may be areas for improvement.
To improve a development workflow, it may be necessary to address the following issues:
1. Do you use git / source control?
Now in reality, if this question is answered with “No” you should quit your job immediately. If this the answer is we are using svn, mercurial - that is ok, but probably suggest to migrate to git.
Even when you are working on your own project that does not be synced with a remote repository you should use git. It is easy to set up and there are a lot of providers like Github, Gitlab, Atlassian Bitbucket if you need to sync it over multiple computers.
The bigger question that relates to this is: “Does every team member understand the Source Control workflow?” The most popular workflow is the GitFlow it is easy to understand and new team members can understand immediately what is going on.
Does your Source Control integrate directly into your build system?
2. Can you make a build in one step?
In most modern development projects this is not enough. If you are doing a Web Development Project, you can use tools like nodemon (Auto reload for NodeJS) or Hot Deployment (Auto reload for Java / Tomcat) to ensure that you constantly build your server. Similarly, you would use something like the webpack-dev server for the frontend.
What I am saying is, you are anyway constantly doing builds of your software. The bigger question is can you also deploy your build without effort? It does not have to be onto a production system, but it could be a testing-server or some other staging system. So when you have to deploy to production you can ensure that it is as hassle-free as possible?
3. Do you make daily builds?
The question should be “Do you deploy daily?” - Whatever you are creating needs to be seen by as many eyeballs as possible. So that the Feedback can get back and influence the development as early as possible. Also, the client should profit from improvements as fast as possible.
This, in turn, does not mean that you should skip testing or quality assurance. It only means that stuff that is production ready should be shipped as soon as possible.
4. Do you have a bug database?
Now bugs are bad, and you need to know about them as well as which features you want to create for your product. So the more pressing issue is how are you tracking all of the development efforts you are putting into the project.
Instead of a bug database, you should have an issue tracker like JIRA or the integrated bug tracker from Gitlab.
The other thing to consider is a dedicated website for “Help us improve our product..” or a publicly accessible “bug database” so everyone that is using your product can easily report issues they are having with it.
5. Do you fix bugs before writing new code?
Well nothing to add here, fix your product before shipping new features. This is more an issue of business intent vs development. Usually, Sales will pressure you to ship faster and will try to cut corners. However, this practice is very expensive in the long run, as customers expect high-quality software. By Apple advertising their products as “magic” the expectation of high-quality software is now the norm. Cutting corners and not fixing bugs is no longer an option. Customers that have the feeling the software is buggy will look for another piece of software that has a higher quality.
On top, of course, is that the longer the bug exists the more money it will cost to fix the bug. So there are enough incentives to first fix bugs and then move on to the new features.
6. Do you have an up-to-date schedule?
Programmers hate schedules. It does not matter if you are ‘agile’ you need to estimate the work you are doing and match it with reality. Only then you can ship things with confidence. Developers need to learn to make a schedule for themselves and not work 14 hours a day just because they did not finish.
But what about extra features? well yes that is called scope creep and yes that needs to be regularly discussed and the schedule adjusted accordingly.
7. Do you have a spec?
You need a spec to start any work. If it is not specified it is unclear what you should build.
That is not an excuse for not specifying exactly what you need at this moment.
8. Do programmers have quiet working conditions?
Now this one is critical for every developer. However ‘quiet’ refers more to that the developers are not constantly interrupted. Have rules like: google it for 5 min before asking a fellow developer. Interruptions of a programmer can cause delays of up to 30min per distraction. To have efficient developers do not interrupt them and let them listen to whatever music they want.
9. Do you use the best tools money can buy?
Every developer has his own personal preferences, allow them to use the tools that they want. Some of the most awesome tools available VSCode is a free tool. Other things like JIRA, and IntelliJ are well beloved and cost a monthly fee. This money is well spent if the developer is happy and gets support from an industry leading tool.
I have seen Java Developers that switch to IntelliJ that were then up to 20% more efficient as before. The program drastically improves code quality and speed in which you develop code. In addition, it has the feature “Inspect Code” that analyses the code for potential quality improvements etc.
10. Do you have testers?
testers should take a look at the software. This includes automated tests, Unit Tests etc. You need to have a Test suite set up to be sure that changes do not affect other parts of the software.
Human Testers should also take a look to ensure that even really unexpected situations do not make the program crash.
11. Do new candidates write code during their interview?
This is a very important thing. HR People have no clue about coding, they cannot evaluate if the developer is suitable and can be integrated into the current team. By enforcing that you need to code in the interview somebody from the dev team needs to be present. That means he also can evaluate the potential hire, plus the potential hire can show off that he has some skills.
This, however, is widely misinterpreted by companies. Some companies have an exam that is more like “find the missing ’;’”, or other similar trivial mistakes that are found instantly by a compiler. Or in another case a company wanted me to complete a task that would require 2days of development effort.
The programming task should be something that is simple and relates to the position the developer is applying for and that can be done during the interview, so it must be short.
12. Do you do hallway usability testing?
“Eat your own dogfood”, people in your company should be able to use the product without any explanation of it. If your own employees cannot use the product or understand what is going on, how should they sell it to a customer? It builds confidence in the dev team that you are doing the right thing and that other people (non-developers) understand what is going on.
Only other Developers are interested in what awesome code you have written. Normal People only care about if they can use the program. Usability is key to any successful piece of software.
The Joel Test V2
- Do you use git / source control? (Does every team member understand the associated workflow?)
- Can you build and deploy in a single step?
- Do you deploy daily?
- Do you have a ticket system for features, bugs, maintenance?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule and devs schedule/estimate their work?
- Do you have a spec?
- Do programmers have a quiet / interruption-free working conditions?
- Do you use the best tools money can buy?
- Do you have Quality Control (Automated Testing, Human Testing)?
- Do new candidates write code during their interview?
- Do you do usability testing?
Source: The Joel Test: 12 Steps to Better Code
images: [”../../../assets/images/Designed by Freepik”]