I feel this list, like so many update attempts before it, misses one of the core parts of the original Joel Test:
> The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question.
"Do you require extensive automated tests for critical path and mission critical features?" cannot be answered quickly, as you have to agree on which paths and features are critical and whether the tests for those paths are extensive. And good luck trying to get an answer to whether your team "values the benefits of diversity".
I also think that the new elements on the list are not as critical as the old ones. I could work for a company that doesn't "automate almost everything that can be automated" - in fact, I would argue that a lot of interesting companies don't. But I am not working without source control ever again.
Hey, article OP / podcast host here. Thanks for the feedback. I think you're right.
When we discussed this topic we were mostly focused on modernizing it, and I think it would take some additional effort to do a sort of cleanup pass and make the additions more binary. Also, in the podcast we went into more depth about each item in the list, so if you haven't already, giving it a listen could help flesh out the thinking. While it's hard to get an answer to whether or not a team "values the benefits of diversity," one thing (I think) that I said on the show is that I will simply refuse to join another team that is 100% middle aged white men (I am a middle aged white man). That's not a perfect rubric, but it's a start, and it's a clear cut binary question.
If we're willing to break out the magnifying glasses, I bet there's at least some nuance hiding behind each of the original Joel Test questions. Do you keep your database schema in source control? Certainly that's easier to do today than it was in 2000. Do you think Joel himself would have considered that a wrong answer if a company used source control for everything but db schemas? I would be willing to bet there are certain things that shouldn't be dealbreakers that, according to the "letter of the law" would be.
4 comments
[ 3.4 ms ] story [ 23.7 ms ] thread> The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question.
"Do you require extensive automated tests for critical path and mission critical features?" cannot be answered quickly, as you have to agree on which paths and features are critical and whether the tests for those paths are extensive. And good luck trying to get an answer to whether your team "values the benefits of diversity".
I also think that the new elements on the list are not as critical as the old ones. I could work for a company that doesn't "automate almost everything that can be automated" - in fact, I would argue that a lot of interesting companies don't. But I am not working without source control ever again.
When we discussed this topic we were mostly focused on modernizing it, and I think it would take some additional effort to do a sort of cleanup pass and make the additions more binary. Also, in the podcast we went into more depth about each item in the list, so if you haven't already, giving it a listen could help flesh out the thinking. While it's hard to get an answer to whether or not a team "values the benefits of diversity," one thing (I think) that I said on the show is that I will simply refuse to join another team that is 100% middle aged white men (I am a middle aged white man). That's not a perfect rubric, but it's a start, and it's a clear cut binary question.
If we're willing to break out the magnifying glasses, I bet there's at least some nuance hiding behind each of the original Joel Test questions. Do you keep your database schema in source control? Certainly that's easier to do today than it was in 2000. Do you think Joel himself would have considered that a wrong answer if a company used source control for everything but db schemas? I would be willing to bet there are certain things that shouldn't be dealbreakers that, according to the "letter of the law" would be.