1. The Joel Test: 12 Steps to Better Code By Tim Denton

2. 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.”

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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:

12. 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

13. 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

14. 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.

15. 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.

16. 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

17. Questions? Comments? ▪ Questions? ▪ Comments?

18. References ▪ The Joel Test: 12 Steps To Better Code – http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html ▪ SEMA – http://www.sei.cmu.edu/measurement/ http://www.sei.cmu.edu/measurement/