Ashley Sheridan​.co.uk

Tags:

I was recently reading an old article by Joel Spolsky where he outlines what he's coined as the Spolsky Test; a twelve-step test that helps gauge the kind of quality you can expect from your development team.

Even though it's 15 years old now, the majority of it still holds true and makes a lot of sense but, as with anything digital, there are a few things that could be updated a little, and some things I thought could do with specific tailoring for web development.

The Original Joel/Spolsky Test

The original test laid out these questions that you should ask of your development 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?

If you think about each of these for a second or so, you'll realise they're essentially timeless, and hold true as much today as they did 1½ decades ago. I think though, that tools have moved on a little since then, and this list is a bit more biased towards traditional software development. Here is my list that I think is better geared towards modern web development:

The Sheridan Test

So, here is the Sheridan Test, along with an interactive element to help give weighting to each question:

The score here is from 0 to 80, with a lower score being better. It's unlikely any team will get a 0, but a score under 30 isn't that bad. If you're looking to improve upon your score, here's why I chose to weight things the way they were:

1. Source control is very important, especially so if there is more than a single developer working on a project. Even if it is just yourself working on the code, good source control is a powerful tool. Git is the obvious choice just for the features it brings to the table, but as long as you use some form of source control (that doesn't include giving patches to Fred) then you are in a good place. Back to the test.
2. The fewer steps to a full build the better. Ideally, if there are multiple steps, you wrap all of these up inside some form of continuous integration tool to do the build work for you. This removes and reduces the human-error risk factor. Back to the test.
3. Frequency of builds is also important. You don't want to have developers work away at something for a week, only to have the build fail right before you're about to show something to the client. Build often, and after a unit of work is completed to avoid problems. Back to the test.
4. It's essential that you record bugs in your software, even if you're only using a spreadsheet to do so. Obviously a dedicated bug tracking tool is better. If you ever assume you are always writing 100% bug-free code, you're probably deluded. Back to the test.
5. Scheduling is important. Ideally you would be fixing critical bugs before beginning new work, otherwise you run the risk of the bugs causing issues further down the line and creating more work. Back to the test.
6. How are the specs for your project organised? You always need to spec things out somehow, or how else can you estimate accurately for the work you're attempting to complete? Having requests reach your developers by email is pretty poor, so you should really look toward laying out a proper spec document at the beginning, or use a bug/task tracker if you're going for a more agile approach. Back to the test.
7. If your developers aren't happy and comfortable, then they will want to go elsewhere, or at the very least, will probably not be working to the best of their abilities. Are they going to be distracted too easily by noise from other departments in the office? Can they at least find a way of getting in the zone when they need to? Back to the test.
8. A good developer is only as good as their tools (mostly) so you should let them use what they consider to be the best tools for the job. Maybe they prefer using Sublime on a Mac, or instead they want to use Netbeans on a Linux virtual machine inside Windows. You should let them use what they feel comfortable with, but do encourage them to try out new tools and be curious about new ways of working, as being blinkered to a particular toolset can be just as bad a rut to get into. Back to the test.
9. Testing is vital for any software, and there's no substitute for a good QA department. Failing that, having someone other than the developers who created the website perform some testing is important, because they can find the bugs that the developers didn't even consider. Back to the test.
10. Just as testing the software is important, so too is testing the candidates who are going for a development position at your company. Make sure that you know the right answers to the questions you're asking, and don't try to deliberately ask questions designed to trip them up on a technicality (especially easy with some programming languages that have about as much consistency as a three year old toddler at lunch time). Back to the test.
11. Websites are, by their very definition, intended to be used by people, and if the UX on the website is poor, their perception of the website is poor. UX isn't something that can be bolted on at the end of a project, so try to ensure it's a consideration as soon in the design/development life-cycle as you can. Back to the test.
12. How closely do the creative people and the developers work together? We've all been involved in a project where the developers were brought in right at the end, only to find out that the amazingly creative idea that was just conceived just wasn't possible given the time/cost/current technology/etc. Just having them work near each other allows them to communicate more and helps avoid these kinds of situations. Back to the test.
13. How innovative is your team? Do the developers get enough time to look at new technologies and tools they can use? If they have no time to do this during working hours, then you're relying on their passion for the work to drive them to do this research during their own free time. That won't always happen, for whatever reason, so allowing them some small portion of the working week to investigate something new can be very beneficial, and might just lead to the build of something amazing. Back to the test.
14. What is the situation of coding standards where you work? Are there even any standards at all? Most web projects will involve many languages, and you should be aiming towards some consistency amongst your developers. The best way to do this is by testing against some form of standards, and do this automatically upon commits (you're using source control, right?) If you have no standards right now, go out and look for something that already exists and use those, or use the best parts of the ones you find. Aim for all your developers to work towards these as best they can, and you'll find that the websites will be of better build quality, more secure, and the time to hand over a project to another developer is greatly reduced. Back to the test.
15. What kinds of security tests do you perform once your builds have been finished? Are you running automated security scans once you deploy a major build? You should be. Every website should be considered vulnerable all the time, and only by testing it and trying to break it can you ensure that it will hold up to what the rest of the world can throw at it once you've pushed your website online. There are plenty of tools and services out there for this, and over time you'll find that your developers will become more security conscious and will be coding more defensively from the outset. Back to the test.
16. Most web projects won't sit still once the initial release has been made, and each and every bit of future work has the chance to introduce new bugs in older areas of the site. As such, some kind of regression testing is important. The best method is a good coverage of unit and integration tests, but at the very least, some form of sanity testing should be performed. Back to the test.