If you’re not familiar with the Joel Test, it’s a list of 12 questions by which you can assess the quality of a software product/team:

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?

It was written up by Joel Spolsky 16 years ago. 16 years! All the way back in 2000, and I know of projects that still have a very bad score.

I agree with the general idea behind the questions, but 16 years later, I would use some other questions. So here is my list of 8 questions. They can be interesting to ask when applying for a new job or when looking critically at your own project.

1. Do you use a modern source control system?
2. Can you verify the health of your codebase in one step?
3. Do you do continuous integration?
4. Can you deploy with one click?
5. Do you have a product backlog?
6. Do programmers have quiet working conditions?
7. Do you use the best tools money can buy?
8. Do you value general best practices over specific technological knowledge?
9. Do you allow working from home?

Source control

Please god, tell me you use source control. Even the smallest of projects can benefit from source control. And by extension, please tell me you use a decent modern source control technology. Personally, I don’t consider the TFS source control system a quality option. If you use TFS, go for Git on TFS.

My issues with TFS could be subject for a separate blog post, but in short, I find it gets in your way more often than it should. Even Microsoft devs seem to prefer Git, as the move to GitHub and the integration of Git in TFS testifies.

Also, put everything in source control: code, scripts, documentation, images, etc. Stop using network shares. You have no way of retrieving lost stuff (except for wasting the IT departments time with backups) and you have no way of easily seeing a history of changes.

Verify health

Is it possible to verify if a change in the code doesn’t break anything else? Is this possible with one click?

Compilation is only the first, most simple check. You should also have automated tests that you can run to see if nothing was broken at runtime.

These tests can be run again and again. Not only do they provide a way of checking if everything still works, they also lead to better code. And finally, it allows you to debug certain scenario’s multiple times, instead of debugging a running application and hoping the scenario you’re interested in will repeat itself.

Continuous integration

When you have changed some code, I hope you commit it to the source control repository (see #1)? What happens then? Hopefully, a build server is triggered to pull in the latest source, build everything from scratch and run all the tests (see #2)?

Even when everything runs fine locally, it happens that the build server will fail. A file wasn’t checked in, the build server works in another time zone, etc etc. Any small thing could lead to a failing build.

Continuous integration also means fixing a failed build ASAP.

A failing build is annoying to other devs, because it might mean they have to wait with getting the latest sources, and they might be blocked from completing their task. This is generally seen as annoying.

One final part of continuous integration for me, is working in small commits. If you wait days or weeks before committing your changes, you’re doing it wrong. Small commits have less chance of breaking things and allow you to progress gradually. When you have 100+ files with changes, and you suddenly realize you’ve gone down the wrong path partially, it’s hard and time-consuming to find the changes you want to revert, while keeping the changes you want to keep. Small commits allow you to just revert the current changeset and try again.

Deployment

Deploying might take more than just one click, but it should be easy and fast. No jumping hoops: no logging in to servers, manually copying stuff, changing registry keys, executing this and that script, etc.

Deployment should happen often and regularly. It should be possible and easy to deploy weekly or even daily. If it’s a pain, fix the pain instead of deploying less. If you have trouble breathing, you want the doctor to fix that, not have her tell you: "well, just breath less".

I’ve worked on a project where I could create a version in our source control system, have the build server build this version, and then click a button to deploy it. This was a breeze and a joy to work with.

I’ve also worked on projects where deploying was an arcane art and involved calling people, figuring out why the new version didn’t work, copying files manually, etc. Needless to say, I didn’t like this way of working. It’s a waste of time, money and fun.

Product backlog

I pretty much agree with what Joel says on using bug tracking software, but I’d expand this to a product backlog in general.

Does the team know what’s coming next? Do they know which direction the project is going? Or does someone just keep them in the dark and tell them what to do each day?

Working conditions

Joel explains why in his original post, and Jeff Atwood has another great writeup on it. Open office spaces might be great for some, but not for everyone. I’m more of an introvert and work better when I can switch off the outside world. That’s not to say I don’t enjoy talking or interacting with people, but when I want to be productive, I’ll often put on my headphones, even in my own office. And you want your team to be productive, don’t you?

Best tools

Assume you’re a carpenter. Would you rather work in a badly aired, cramped and hot workshop, with a hand-saw and a screwdriver, or in a spaceous room with light, clean air and modern power tools? Where would you be most productive?

Often, with sub-par technologies, developers are constantly jumping hoops, searching for and applying workarounds, getting frustrated, wasting time, watching YouTube,… This is not the way to get the best out of a team. Good developers want to be productive. They don’t want to be wasting time, mucking around, watching YouTube. But torture them enough with idiocies that kill their productivity, and they will.

Best practices

How many times have you seen job descriptions that have this kind of list:

• C#
• ASP.NET
• NHibernate
• MSSQL
• Autofac
• etc etc

And how many times have you seen one where it’s clear they value knowledge of SOLID, TDD, DDD, etc etc and knowing C# is a nice to have?

Specific technologies and languages can be learnt in a reasonably short amount of time. Especially if you use them 8 hours a day. But learning best practices is a longer and slower process. It involves making lots of mistakes. It involves writing crappy, unreadable, unmaintainable code and then admitting to yourself the mess you made. It involves failure, and learning from it.

Depending on your experience, you can learn a new language in one day, one week, one month, definitely one year. And then it more or less stops, except for some special stuff you hardly ever use. But being able to write modern, readable, maintainable code, is something you learn everyday, again and again.

So does the team or company you (want to) work at value language and tool knowledge over general principles and best practices, or the other way around?

Home work

Working from home should be easy for the IT industry, wouldn’t you think? Most of my non-tech friends think so. Most of my tech friends think so. Yet, a depressingly low amount of companies actually allow this.

This is a subject for a separate post, but in short:

• happier employees
• no hassle if public transportation strikes (very interesting for Brussels-based companies)
• it’s entirely possible to agree on rules (i.e. no more than x days a month, not on Monday,…)
• yes, it does require some setting up (communication channels, VPN,…)

Conclusion

Whenever I get an offer (which is almost daily now) that is more or less interesting (not daily), I now send back these questions. I’ve received some fairly interesting responses. Also some where certain questions are strategically avoided.

But it gives you an initial view of the company. As I’ve said in my post on attracting developers, the company is the candidate, not the developer. That means you, as a developer, should be filtering out the candidate companies before going to an interview.

If you’re not looking for a new job, a questionnaire like this can be useful to have a critical look at your team or project. The nice thing about a test like the Joel test, is the yes-no question format. So set up your own question list and see how you or another company scores.