黑料吃瓜网

If you're a SaaS business, you probably think your software development team is pretty good. But, can you prove it?

We could start by gathering employee feedback and asking questions like, "On a scale of one to ten, how good is your software team?" and, "How would you rate your software production?"

But, most of these questions don't provide empirical information about your business. There are many ways to evaluate software teams and employee surveys like these make it easy to skew answers in your favor.

Luckily for us, a software developer named Joel Spolsky made our lives a bit easier. In this post, we'll break down the Joel Test and explain how you can use it to evaluate your software development team.

Who Is Joel Spolsky?

Joel Spolsky is a software developer living in New York City. He is the CEO and co-founder of Stack Overflow, a network of Q&A sites. He also co-founded , a software company, and incubator based in New York City.

Spolsky created a blog in 2000 called Joel on Software where he discusses software development, business, Internet, and management. This is where the Joel Test was created.

What Is the Joel Test?

The Joel Test is a very simple and quick test that rates the quality of your software team. Rather than including open-ended responses, this test has 12 yes-or-no questions that determine whether your programming team is up to par.

A score of 12 is perfect. 11 is considered tolerable, and 10 or below is unacceptable. It's a tough test to pass, especially since most software companies have scores of 2 or 3. With a score that low, it's tough to compete with a company like Microsoft that maintains a perfect score.

And, if you are landing an 11 or 12, it doesn't mean you are all set, either. There are many other factors that are essential to a software team. However, passing these 12 questions will ensure that you have high-functioning, customer-centric employees.

The 2021 Guide to the Joel Test for Programming

1. Do you use source control?

Source control (or version control) tracks and manages changes made to code. Changes are marked by a tag, known as the "revision number." The original code is deemed "revision 1," and, after the first round of edits, it becomes known as "revision 2," and so on.

Source control is important because programmers can work together on code and track changes over time. This makes it easier to highlight mistakes and correct them before they cause major problems. And, since the source code gets uploaded into every programmer's hard drive, it's much harder to lose revisions.

2. Can you make a build in one step?

A "build in one step" is the ability to combine multiple sections of code, written by various programmers, into one top-level program or tool. As you build, the source code of various tools or features should combine into a single program that can run on its own.

It's important to have a "build in one step" because large programs take more time to complete if they're written by a single person. Instead, it's faster to divide it up into multiple sections, so work can be distributed between several developers. In the end, all the sections and sub-sections are combined into an all-inclusive program.

3. Do you make daily builds?

When using source control, it's easy for programmers to break the build when writing new code. What's even worse is when they don't realize it's broken. A broken build can stall production until the issue is recognized and resolved. To safeguard against this, your team should be conducting daily builds to verify if anything has broken.

If something shows up during the daily build, programmers can check the code that got added or modified to figure out what broke it. Then, fixing the code becomes the responsibility of the person who added that change. This system ensures that errors are noted and fixed as soon as possible and that each programmer can navigate the build.

4. Do you have a bug database?

It's impossible to remember every bug in the code -- especially when there can be so many. For instance, if you click a link and realize it's dead, that action may be automatically saved into a bug database. Since bugs can be reported in a variety of ways, it's important to collect all reported bugs into one database because, if not, they may get forgotten and never fixed.

Additionally, bug databases can work as for programmers. You can use the bug database to see if a similar problem has been reported and if there are steps on how to fix the issue.

5. Do you fix bugs before writing new code?

When writing, you may prefer to write first and edit mistakes later. Many programmers have a similar mindset when it comes to writing code and would prefer to fix bugs after the original code is written. However, this can lead to major flaws, making it more important to prioritize bug-fixing than writing new code.

The longer you wait to fix a bug, the harder it will be to remember where the bug occurred. Fixing it the same day will take minutes while fixing a bug that was written weeks or months ago will be stressful. And, if the product has already shipped, you'll have to recall it and waste copious funds.

Additionally, it's much easier to predict how long it will take to write new code than it will take to fix a bug. This is because fixing a bug depends on when that code was written and how long it will take to track it down. Instead, if bugs are fixed immediately, you can schedule more time to write new code.

6. Do you have an up-to-date schedule?

It's essential to know when code is going to be complete. It's simply unacceptable to leave this to the programmers' leisure. Advertisements, shipments, and even the general satisfaction of customers all ride on code being written in an efficient timeframe.

Having a schedule makes your programmers' work easier. With a schedule, programmers can sort through the list of features to add and weed out the unnecessary ones that will take up too much time. This will ensure your programmers are hitting deadlines and working on code that's essential to your product's success.

7. Do you have a spec?

Product specs are blueprints that describe exactly what the product will do, what it should look like, and how it will perform. Additionally, these guidelines can help product management optimize the product's features for your target audience. They'll outline all the information about the product, so every member of the product development team will know exactly what to create.

When products aren't built from specs, they're more likely to have bugs, be poorly designed, or take too long to build. This wastes time and money, making it risky to write code without having a spec. Whether it's written by your programmers or external writers who are hired for the job, specs should be written and approved before programming begins.

8. Do programmers have quiet working conditions?

According to Spolsky, it's important for software workers -- among other knowledge workers -- to get "in the zone" to get productive work done. Being intently focused is great, but it's a difficult state to attain. After all, it takes the average employee about 15 minutes to start working at one's maximum productivity level.

The simplest distractions can lead to a severe lack of productivity. Overhearing conservations, taking phone calls, and being interrupted by coworkers can result in 15 to 30 minutes of wasted time. So, giving programmers quiet offices, rather than open cubicles, can lead to more production.

9. Do you use the best tools money can buy?

The best companies provide their employees with the best tools. Without them, your employees won't be able to produce a high-quality product. If you want your software development team to succeed, then it's important to invest in the best software development tools.

10. Do you have testers?

It's vital that your software team has testers -- about one per every two or three programmers. Without testers, you may be sending out defective products or wasting money by having programmers -- paid about $100 per hour -- test products that could be tested by people who are paid $30 an hour. Additionally, testers help refocus your programmers', so they can spend more time coding and troubleshooting.

11. Do new candidates write code during their interview?

You probably wouldn't hire someone for a job without seeing if they can perform that job. For instance, would you ever hire a graphic designer without seeing their creative portfolio? Or, would you hire a baker to make your wedding cake without first tasting their samples?

The sentiment should be applied to programmers. Of course, you can still select candidates based on their resumes, references, personalities, or answers to interview questions. However, their ability to write code during the interview should be the most important. After all, that's what they'll be doing all day.

12. Do you do hallway usability testing?

is when you stop someone who walks by you in the hallway and ask them to use the code you just finished writing. Having five random people test out your code will show you 95% of the usability problems with your code.

User interfaces are hard to assess when you're the one who has been staring at it for hours on end. It's important to get fresh eyes on your code to point out issues you may have overlooked. And, since hallway usability testing is both quick and free, you can continuously test your code until it's perfect.

 For more software development tests, learn how you can perform a heuristic evaluation.