My Reflection on Joel Test
Its been long time since I landed on Joel Test page but the echo still resonates in my mind. May be a bit late to read it at 2014, but amazingly, it still give many benefit to me.
Just a brief intro, Joel Test is a blog written by Joel Spolsky — currently as chairman of the board for Stack Overflow, Glitch, and HASH — giving idea to easily measuring how good a software team is, assessment at no cost. Take 3 minutes to answer yes or no to these questions:
easy isn’t it? Wait, how much you score? as mentioned in the article, good software team must have all those 12 yes, and 11 yes still tolerable, and it said “most software organizations are running with a score of 2 or 3”.
That’s it, even this article written in year 2000, but still need effort and discipline to keep it up. Thanks to Joel, since then it seem raising many awareness and discussion online. I don’t know how relevant it is for year 2021, but many still discussing and I do still reflect on it. Although many changes happen since then, lets take a look at these:
- Do you use source control?
By the time article written neither git or svn already invented, so it is a big effort to have one. Now in 2021, it’s the norm, you may offend someone by asking that question. But what can be matter now -even we all already using that- there’re still awkwardness in using it. May be due to different workflow understanding or sometimes due to team restrictions. So, may be a yes still need further ,inspection. - Can you make a build in one step?
Today is common to have IDE with integrated compiler, and all done in just a single click. Like the previous, this also a norm. Really? Wait, IMHO, this depend how we begin with when starting to develop apps, there’re still options that left us stuck in multiple steps of integration, a lot of command line sequence and so on. - Do you make daily builds?
Somehow, I still questioning how effective this in my projects, but for matter to pass the test, I do it too, its only a click away isn’t it, or a line of cronjob in linux, or just let our repository host do that for us. By the way, I still found some of opensource software that have nightly build release, my thumbs up for them. - Do you have a bug database?
We can consider (read: pretend) this done, but honestly I still struggling to have this. Either lack of good written feedback or lost it somewhere. Yes we have many bug tracking tools, but it only work if maintained properly. - Do you fix bugs before writing new code?
Same as previous, consider this done. May be it is easier to have a new feature up, but remember, multiple bugs can be harder to fix, and ignoring this can make our life harder. - Do you have an up-to-date schedule?
Up until this one, I think any today team management tools can help to get all above question answered yes. I even want to say that all question above are related. Say that if team already good at 1, 2, and 3, then it will be easier to track bug, which is 4. And if all done well to 5, then it will be easier also to keep schedule up-to-date. Otherwise, if fail to do so, say that handling complex bugs after pushing all feature up with unproper source control, it can turn the schedule far away. Sure we don’t want that to happen. - Do you have a spec?
Now this one and below are part of the process, but sometime we missed it, may be because some of us either eager coder or scope creep. IMHO, since spec seem included in term URS, but I think it is not the same. I’d prefer spec is part of architect design rather than user request side. Say that in URS “internal storage is 8GB or more”, spec should be “internal storage: 16GB Flash”. The first one still open to may be unlimited possibilities, while the 2nd is narrowed to specific chipset. For further more about spec, Joel also have following article about it: Painless Functional Specifications. - Do programmers have quiet working conditions?
Nowadays, this can be the most challenging part to get a yes. It is hard to get dedicated space or room, even cubical desk already rare thing to have now. At other side, virtual space and schedule also already booked, meeting after meeting and notifications in social media and chat like a heavy stream in the river of noise. Thanks to “work from home”, now programmers can have more quiet time, hmmm, that’s can be another challenge. - Do you use the best tools money can buy?
This one sometimes debatable. With so many community and opensource tools built and easy access to online resources at no cost and no time, it is really tempting and hard to leave. But believe me, I once bought a $2.5k design tools (actual price $5k, with 50% discount due end year sale), it is really different and that price really matter. - Do you have testers?
There’re many discussion about automatic testing, but I think each manual and automatic have its own part in testing. Sometime I simplified this one to challenge friends for a lunch if they can found a bug. Sometimes using a rather meany way, but at the end we still laugh together. - Do new candidates write code during their interviews?
I tried to comply this since first read the article, and result quite different, atleast I know more detailed with candidates ability, good and bad about him in programming, which can help in proper initial placement and improvement plan. - Do you do hallway usability testing?
Don’t be confused with question 10th, this one I think be like asking random users and find out how they managed to use our software or product.
It seem is not hard to get full 12 score nowadays. As question 1st to 6th more likely answered by most team management tools, either free or paid. And also question 7th to 12th likely already embed in any IT team process. As usual, there’re many debates regarding to tools and process, but I prefer to focus inside by challenge my self to do self assessment and give help to team and team mates. No need to wait for top level assessment, we can start from any team we involved in.
