So there’s this really smart guy. His name is Joel Spolsky. He’s written a lot of smart stuff over at joelonsoftware.com that makes a lot of sense. One of the things that he and a lot of other industry talking heads are big on is something called The Joel Test. It’s a test for programming groups that determines whether or not they’re doing things the right way. By following the 12 tests he puts forward, we can tell if a group of programmers is succeeding or failing in their main job, which is writing solid software.
Here are the 12 tests:
The Joel Test
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?
But here’s the thing – he’s used to big, long-term software projects where there’s a large team that all works on the same thing. What happens when you need to apply this to small teams that works on lots of smaller projects? Well, some stuff has to change. Here’s how we at SCC|Digital see these guidelines and apply them to our own organization:
1. Do you use source control?
We use source control. We use it for everything. We use a system called Git, which is part of a new breed of distributed source control systems. What does that mean? It means that we don’t need to be on the network to commit, so we can do work from the train. It means we each can have our own branches of the code, and merge them together quickly when it comes time to deploy. While stuff like SVN and CVS may work when you have fewer, larger projects, we find that Git is much more convenient and reliable for small projects. Git makes us more productive.
2. Can you make a build in one step?
Our adaptation if this is – can you deploy your applications in one step? The answer to this is now yes. We use an open-source deployment system which means any time we need to deploy our apps we can do so literally at the click of a button. We also can roll back applications to previous versions, again with a single click, if we don’t like the results of the deployment.
3. Do you make daily builds?
Joel uses compiled languages. We don’t, so here’s our question – do you have a staging site? Something that mirrors the live environment so you can test your changes before they appear in public? We set this up for all the sites we administer. Nothing goes live without being vetted by both the programmer who wrote it and another pair of eyes. I can’t tell you how many times we’ve avoided disaster this way.
4. Do you have a bug database?
It doesn’t matter what tool you use – Lighthouse, FogBugz, Redmine, homegrown, etc. – when requests come in, there needs to be an easy way to keep track of them and who’s assigned to what. When someone finds a problem, there needs to be a record of it so it isn’t forgotten about. We use Redmine. We love Redmine. We can’t live without Redmine. It integrates with our source control (#1). It keeps us on track.
5. Do you fix bugs before writing new code?
That shiny new contact form won’t be worth much if the whole site is down. We test our sites regularly and fix the problems we find first.
6. Do you have an up-to-date schedule?
1/3 of all software projects fail. They go over budget, they go over time. The only way to manage effectively is to keep track of where you are. This is the same no matter what kind of software you’re writing.
7. Do you have a spec?
A spec is a definition of what you’re trying to build. It’s a list of features and how they need to behave. It’s a sitemap, wireframes, and user flows, along with other documentation. We create Information Architecture (subject of a future post) documents for every site we create. This gets everyone on the same page with what’s to be done and how we’re going to do it. Creating these documents takes time, but it speeds up development in the end, as everyone involved in the project, from developers to designers and managers to clients, understands exactly what’s being done.
8. Do programmers have quiet working conditions?
Here’s one place where we must disagree with Mr. Spolsky. Web developers don’t just crank out code. They act as consultants, designers, support specialists, and general Mr. Fix-Its. We use QA procedures to make sure stuff doesn’t fall through the cracks and put on headphones when we need to, but we’re always available, which means sometimes things get loud. But then, that’s Advertising.
9. Do you use the best tools money can buy?
Interesting – in Web Development, as in life, we think the best things are free. Best web server? Apache – free. Best programming languages? Open source, and free. Best server operating system? Linux – free. We drop money on tools when we have to, but it’s not as often as you might think. We all work on Macs, which we believe are the best tools for the job, but nearly all the tools we use for development are free and open source.
10. Do you have testers?
Yup. We have a system in place that makes sure everything gets checked multiple times before it goes out the door. Then we check it once it’s gone out. Then we check it again a week later. And a week after that. That’s only responsible.
11. Do new candidates write code during their interview?
Yup. And get quizzed like crazy. Dreamweaver doesn’t get it done. The only way to build things right is to build them by hand, just as in every other craft.
12. Do you do hallway usability testing?
Yup. We make sure the Account Managers can use our sites. We make sure the Receptionist can use our sites. We try to make things simple for users, even when that makes our developer’s lives more complicated.