Tidbits on software development, technology, and other geeky stuff

The Joel Test - Updated for Today

You have heard of The Joel Test, right? It’s “a twelve-question measure of the quality of a software team.”¹, from Joel Spolsky the super talented guy behind applications like Excel, Stack Overflow, FogBugz and Trello. I have been familiar with this list for quite some time and have worked for more than one company that looked to this list as the model for doing software development right. You know, it’s a good list and definitely provides some solid guidelines that most dev shops should strive for. Here’s the list:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

The Joel Test was written 16 years ago in the year 2000! That is a really long time ago. Let’s look at some things that have happened since The Joel Test was written:

A lot of things have happened since then. I certainly realize that the passage of time does not automatically prescribe that things change and I will be one of the first to point out that fundamentals rarely change in the world of software development. However, 16 years is long enough that some fundamentals can start to be challenged. It should be long enough for mistakes to have been made and more lessons to have been learned.

Lately I have been seeing some blog posts around that pitch what an updated Joel Test would look like. I like this idea and thought it would be fun to propose my own. Please know, just because I drop a few of the original items from the original test, this does not mean I do not think they are not important. Rather, I chose to list things that I think are important and relevant in the current software development landscape. So, for example, below you’ll notice I omit Joel’s original #1 - “Do you use source control?”. I still think source control is a must but thankfully so do 98% of other software developers out there today (maybe in no small part thanks to The Joel Test!).

So, here we go. In no particular order, this is my list:

  1. Is your build and delivery process completely automated? - Can you build and deliver (deploy) without the involvement of manual steps?
  2. Do you write and run automated tests? - Is automated testing a fundamental part of the development process? Do you have unit, integration and/or acceptance tests that are run continuously during the build process?
  3. Do developers have quiet working conditions? - I’ll gladly leave this on my list because I think it is so important.
  4. Do you use the best tools money can buy? - I’m keeping this one for sure. Joel was spot on with this and I wholeheartedly agree on the priority of this. Tools are dirt cheap compared to the time of developers.
  5. Do you use tools to track bugs and features? - Is there a tool being effectively used by the entire team to keep track of bugs and features?
  6. Do you use a defined development process to prioritize work and communicate status? - Are you employing a defined process like Scrum, Kanban or a hybrid that supports assigning priorities and communicating status to the team and stakeholders?
  7. Do you do code reviews? - Is all code being reviewed by a peer or lead on the team to discover defects, foster constructive feedback, and encourage accountability?
  8. Do developers collaborate with software stakeholders? - Do developers communicate with, work with and have empathy for those that use (or those that represent those that use) the software?
  9. Does the team communicate regularly? - Be it a daily stand-up, culture supporting ad-hoc meetings or scheduled one-on-ones, is there regular communication among the team members that supports collaboration, accountability and productivity?
  10. Do new candidates write code during their interview? - This is another one I’ll certainly leave on the list. I am glad to see most shops requiring candidates write code during interviews these days. Be it an in-person whiteboard exercise or a remote CoderPad problem, candidates should be writing code during the interview process!

Look there, I only have 10. I’m fine with that and think the above list is good litmus test for a healthy, productive modern software development team. I’d be proud to be on a team where all 10 of these are present. Actually, I am on a team like this, at YNAB!

¹ - quote pulled from SO jobs

Discuss on Twitter