Thoughts on the Joel Test for evaluating employers.
Back in 2000, Joel Spolsky wrote the infamous Joel Test article. The Joel Test offers 12 conditions that a self respecting developer should expect of their employer. These 12 conditions can be used as a quick and dirty way of evaluating prospective employers prior to accepting a work agreement. While Joel does mention that these 12 conditions alone are not enough to guarantee an employers success, it does offer a foreboding warning that missing even a few of these basic conditions are a sign of needing serious help. While I do agree with some of the points that the Joel Test brings up, I think some of the points are not simply not as important as indicated, or are too strictly worded to be practical in many real world scenarios. With that in mind I will be analyzing each Joel Test condition and offering my own thoughts. While it might be nice to have a 12/12 score for your place of work. It might be feasible to improve the score of your current employer rather than searching for a new employer with a higher score. If your current employer is not meeting a condition you feel is important, maybe there is something you can do about it.
1. Do you use source control?
This is an easy one to agree with. If a software company does not use some version of source-control by the year 2016, I would have serious doubts about that company's vision and business protocols. The cost of using version control is negligible, but the benefits they afford a team of engineers is invaluable. Source control allows versioning, code sharing and reviews, distributed team coding, and viewing the context of each line of code through the history of a project. Free online tools that integrate with source-control systems are numerous and offer further benefits such as automated build tests, documentation and online public repositories.
2. Can you make a build in one step?
This is a point that I can really agree with and yet find the wording to be a bit strict as well. I would beg to argue that there are occurrences where a company can technically fail based on this wording and yet be in a very reasonable situation. The realistic reality is that if the build system requires a few commands in succession to complete, this would be just as acceptable. A competent developer could make a shell script to run those commands and add it to the repository in under five minutes. I believe the intent here is to avoid companies where the build system is extremely fragmented and/or it would take great effort to bring automation to the build.
3. Do you make daily builds?
Number three might be my biggest disagreement. I understand Joel is speaking largely in part to low level compiled code where this would be a much larger issue. However this fails to stand up to argument for me for 3 reasons. First and foremost, there should never be an issue of breaking the build because in a team environment, nobody should be directly working on the master branch. The process of integrating code to the master branch should only occur after a thorough code review and testing which would catch these breakages. Secondly, with version control, if a build were to get broken, the offending commit could be removed and the team could continue working unimpeded until the original programmer returned to fix it. Finally, I once again find the wording here a bit too strict to apply to realistic companies. Is a company failing if it only builds every other day rather than daily? Does a daily build include projects with multiple micro-services? What about companies with less aggressive release schedules or development jobs supporting legacy software. There definitely can be benefits to catching bugs early by running full integration tests on a fresh full build, but this may not alway be a necessity depending on the team structure and specification.
4. Do you have a bug database?
Once again I find myself agreeing with the intent while arguing with the realities of penalizing a company for the absence of a bug database. Joel even mentions a simple 5 column spreadsheet could be a suitable substitute for a bug database. I am positive in larger software projects, where there is a lot of moving parts and it becomes harder to track down and rectify bugs that this is a necessity. The absence of a bug database however may not necessarily be a terrible sign. The utility of a bug database increases as the number, severity, and complexity of the bugs in the code base increase. A good development team should hunt down bugs and eliminate them as soon as possible. The absence of a bug database may indicate the company prioritizes fixing bugs to such a high degree that the utility a bug database offers is lower than the cost to maintain it.
5. Do you fix bugs before writing new code?
Perhaps this was Joel's way of accommodating my previous point. I truly believe that all the best companies should be more concerned with fixing bugs than developing new features. Foremost because developing new features is much easier when they are developed on a solid bedrock of properly functioning code. A company will do well to be known for 1-2 incredible rock solid features, rather than hundreds of buggy, poorly implemented one. Clients need to be able to count on your product.
6. Do you have an up-to-date schedule?
Here is a point of contention. For software developers, this likely should not factor much into your decision. Any company that is able to stick completely to its schedule is doing that by one of two methods. Either by having a very reasonable schedule which can often mean the company is not pricing itself very competitively or by having an unrealistic schedule and then forcing their developers try to live up to the schedule via overtime and constant sprints. A company willing to have a slipping schedule for the sake of quality and developer morale is likely to be a better company to work for in the long run.
7. Do you have a spec?
This is a point that can not be stressed enough. Personally, I find a project where the spec can not be pinned down can become very frustrating. Having specifications allows for better design, greater working efficiency, and decoupled modules. While it can sometimes be fun to dig in and get dirty with code rather than document and plan, this tends to lead to re-writes and more costly refactoring. A well run organization will ensure that developers are assisted with knowledgeable managers that can query clients to get detailed useful specifications and prevent developers from having to do exploratory coding.
8. Do programmers have quiet working conditions?
The single greatest deterrent to efficiency for the modern developer is distractions. The internet is distracting, our computers themselves are often sources of distraction, and when you throw in desk and cell phones, tablets, brazen coworkers, managers, clients and investors, its amazing people can focus at all. While it is important that your team remain in communication and on the same page, constant meetings and discussions can actually have a negative effect in this regard. Just as you schedule time for meetings, you should also ensure there is plenty of time scheduled for individual work periods. These should be scheduled such that they are long and uninterrupted. My biggest frustration as a programmer is being interrupted when I am in the flow. While it can sound silly, the context switch that the mind must make between programming and verbal communication can be extremely jarring for some developers. Each time they make this switch it can take as much as 15-20 minutes to get back into their usual flow. Many developers dislike spending too much time away from their favourite text editors and terminals.
9. Do you use the best tools money can buy?
I find this point a bit elitist but its also a matter of perspective. It is true that more powerful hardware and more expensive software correlates to increased efficiency. Its true that you can buy your way out of problems but the law of diminishing returns suggest that the more you put into this category the less you get back. Modern technology has reached a point where processors are no longer being made faster via increased processor power, but rather via increased parallelization, and open source software is proving itself more reliable, more affordable, and more extendable. Applications can be more easily scaled horizontally than vertically, and the costs of middle grade hardware have never been more reasonable. All my favourite software that I currently use is free and open source. Ill take Sublime Text over Visual Studio any day of the week. That being said, I would be upset if my company wasn't willing to spend the money to get me the hardware and software I need to be at maximal efficiency. Especially since it would be in there own best interest to do so.
10. Do you have testers?
Here is a point I feel very on the fence about. On the one hand, I do agree with Joel that testers can often be employed at a much cheaper rate, and programmers often dislike testing, especially manual testing. That said, I am not sure the economy he mentions is as large as he believes. While it is true testers can be acquired at a cheaper rate, the best testers should be commanding similar wages as your developers. Secondly, while it can be beneficial to have new sets of eyes on a code base to help test and find bugs, adding new employees for the sake of adding silos to job categories can actually hurt project efficiency. The mythical man-month has been beaten to death, but it stands to reason it applies here as well. Finally, in very complex code bases, sometimes its simply a matter than the ones best suited to writing test code are the ones involved in writing the code themselves as the cost to bring testers up to speed could be more expensive.
11. Do new candidates write code during their interviews?
I do not disagree in principle with this point. New candidates should be expected to code in an interview. Where I may find some fault in this point is actually just in the execution of coding interviews. I agree that not having some aspect of coding in the interview process can allow for an organization to fill up with sub-standard coders. That being said, companies should execute their coding interviews in a manner that reflects real coding situations. Prospective employees should be allowed to consult the internet/external resources/interviewer without penalty so long as they are able to use the information efficiently to solve the problem at hand. I even think homework problems are a good way to go as they remove some of the inherent stress an applicant may feel as they work through the problem in the comfort of their home. Prioritize clean code that takes time and research over the quick solution.
12. Do you do hallway usability testing?
I agree whole-heartedly with this point. It is very integral that you are able to consult your co-workers for their opinion for all code commits. Coding is a shared activity between all your programmers. No code typically runs in isolation, and its important to roll the skills of your entire team into the entirety of your code base. More eyes, on each line, and on all lines, removes the harder to find, systemic bugs. In my opinion, the best companies will not commit to master without a proper code review of the pull request.