Judging the quality of software is difficult. There are approaches that use metrics like code coverage as well as approaches that define quality as “a function of how much it changes the world for the better”. This can be interpreted as meaning that user satisfaction is more important than functional and structural quality.
And how do you judge the quality of a software team? Since software engineering is a really complex process, it is almost impossible to accurately determine the quality of a software team. This is where the Joel Test comes into play.
The Joel Test is a creation of Joel Spolsky, Co-Founder of Stackexchange and Fog Creek Software. It includes the following questions:
- 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?
Easy, isn’t it? We answered all of the questions and wrote down some thoughts about their importance for the quality of a software engineering team.
Yes. Git in combination with GitHub makes it easy for everyone to review and discuss about code. Thanks to PHPStorm, we can check all the changes ever done in a file right in our IDE. Since we are doing lots of multi platform development (Linux, Mac, Windows), with lots of different languages (C#, Java, Php), Git is the perfect tool as it is available on all of these systems.
Yes. We can install Ribbl as well as our unit-testing environment within a few seconds by executing one single command. We integrated this command into the PhpStorm IDE, so we don’t even need to type anything into the terminal.
Yes. We did setup our internal Jenkins CI server which is building and testing our software after every commit on 3 different PHP versions. For all public projects (like Fusonic-Linq) we have integrated Travis CI into our build.
Yes. We use the GitHub bugtracker for all public repositories. Beside that we are still back on Mantis - a quite old-fashioned piece of software as some of you will know.
Not always.We track bugs on our scrum board. In our Daily Scrum, we estimate the time required to fix them and discuss about solutions. All Bugs are documented in our bug tracker. However, we sometimes start to implement new features, even when a few bugs are still not fixed.
Not really. We use Scrum with sprints of 2 weeks. Basically, Scrum depends on schedules. At the very beginning of every sprint, we plan what tasks we will do in the next two weeks. Our scrum board gets updated during our daily scrum meeting. Howerver, we don’t really have a long-term roadmap.
Yes. Before implementing a new bigger feature, we create a requirements documents which includes the specifications of the expected outcome. If there is also a design part, this document will also include UI-mockups and UI-workflows. If the new feature is non-trivial or may has a big impact on other areas, we are also creating design documents, which include class and api documentation. These documents will be discussed and polished in our requirements meetings.
Yes. This is extremely important to us. We decided not to schedule any meetings before 3 PM. Most of us even completely opt out for some hours by saying the magical words “I bin im Tunnel, Habidere! (I’m in the tunnel, good bye)” and simultaneously putting in their in-ear-buds.
Yes. All of our developers are equipped with high end desktop PCs with SSDs and two monitors. Besides that, our tables are adjustable in height (by pushing a button). With these tables, it is even possible to develop while standing. When it comes to PHP software development, we use PhpStorm as our IDE. In the .NET C# world we use Visual Studio on Windows, and Xamarin Studio (Monodevelop) on Linux and Mac OSX.
No. At least no dedicated ones. Some of us focus on testing tasks because they like this kind of work, others don’t. Still, there are some rules:
- Write test scenarios
- The one that executes the tests should not be the same person that wrote the code
- Turn your brain on
Yes. New candidates do a one-day trial period in our office. Usually, in that day they have to cope with a task we give them. This is usually developing a small web application. They have the whole day to solve the problem. When they are finished, we do a shared code review.
No. We think that this is a point where we could improve.
If you want to learn more about the test, read Joel Spolsky’s article on his blog. Even though this is a highly irresponsible and sloppy test, we think that these 12 questions say a lot about the quality of a software team. What is your score? And more important, what do you think about the Joel Test?