The Joel Test: 12 Steps to Better Code

By Tim Denton

The Joel Test vs SEMA

▪ The Joel Test was created to replace SEMA

▪ SEMA (Software Measurement and Analysis)– Measurement and analysis of gathering quantitative data about

products, processes, and projects – That data is then analyzed to influence your actions and plans for

software development

▪ Joel's thoughts on SEMA: – “It will take you about six years just to understand that stuff. So

I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team.”

The Joel Test vs SEMA

▪ The Joel Test– Only 12 questions ▪ Ideal score 12▪ 11 is tolerable▪ 10 or lower = serious problems

– Each question has a YES or NO answer– Line of code creation irrelevant– FAST!!! Takes around 3 minutes

Step 1. Do You Use Source Control?

▪ Source Control - the management of changes to documents, computer programs, large web sites, and other collections of information

▪ Allows a programmer to revert to an older version of code at a saved point in time– If a mistake is made, it can be rolled back

▪ Examples of source control– Github– Bitbucket– Team Foundation Server

Step 2. Can You Make A Build In One Step?

▪ On good teams, there's a single script that can be run to:– Conduct a full checkout from scratch– Rebuild every line of code– Create the executable in the desired versions and languages– Create the installation package

▪ If the process takes any more than one step, more chance for errors

Step 3. Do You Make Daily Builds?

▪ Daily builds insure that no breakage goes unnoticed– Large teams, do the daily build every afternoon (lunchtime) – Small teams, every 2-3 days (user discretion)

▪ If the build worked, great! – Everybody than has the latest version of code continues working

▪ If the build failed, fix it!– But everybody can keep working with the unbroken version of

code

Step 4. Do You Have A Bug Database?

▪ Bugs must be formally tracked or low quality software will be created

▪ Why? Because programmers can continue to write bugs over and over again without realizing or knowing they are doing it

▪ Bug Database can be complicated or simple, but must have:– Steps to reproduce the bug– Expected behavior– Observed (buggy) behavior– Who it's assigned to– Whether it has been fixed or not

Step 5. Do You Fix Bugs Before Writing New Code?

▪ In general, the longer a programmer waits to fix a bug, the costlier it is to fix that bug

▪ And if a bug is found in code that has already shipped, it is even more expense to fix

▪ Bottom line, fix bugs before writing new code

Step 6. Do You Have An Up-To-Date Schedule?

▪ There are many planning decisions that the business needs to make:– Demos– Trade Shows– Advertising

▪ Forces development teams to decide what features are going to be implemented or not

▪ Prevents Scope Creep

Step 7. Do You Have A Spec?

▪ When creating a spec at the design stage, a problem can be easily fixed when it is discovered before it ever gets to code

▪ Software that wasn't built from a spec is usually badly designed and the schedule gets out of control.  – Netscape started over from scratch 4 times

▪ No Spec = No Code

Step 8. Do Programmers Have Quiet Working Conditions?

• Knowledge workers need space, quiet, and privacy to be productive

• Issue: Getting into "the zone" is not easy

• Takes an average of 15 minutes to start working at maximum productivity, “the zone”

• Issue: Very easy to get knocked out of the zone:

Step 9. Do You Use The Best Tools Money Can Buy?

▪ Far cheaper to get programmers new tools vs. paying their competitive salaries!

▪ Tools– Latest computers– Multiple monitors– Fastest compilers

Step 10. Do You Have Testers?

▪ If your team doesn't have dedicated testers– You are shipping buggy product– AND/OR– You're wasting money on programmers doing the work of testers

▪ Should be at least one tester for every two or three programmers

Step 11. Do New Candidates Write Code During Their Interview?

▪ Would you hire a magician without asking them to show you some magic tricks?– No!

▪ Would you hire a caterer for your wedding without tasting their food? – No!

▪ Do whatever you want during interviews, but make the candidate write some code.

Step 12. Do You Do Hallway Usability Testing?

▪ A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote.

▪ If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

Conclusion

▪ The Joel Test is a unorthodox, but effective test. – Analyzes the productivity of the software development team – Identifies potential problems or shortfalls the team has or may

encounter– No learning curve– Fast

Questions? Comments?

▪ Questions?

▪ Comments?

References

▪ The Joel Test: 12 Steps To Better Code– http://www.joelonsoftware.com/articles/fog0000000043.html

▪ SEMA– http://www.sei.cmu.edu/measurement/