Joel Test for Better Code Quality: 4 Essential Steps
Discover the Joel Test, a simple yet effective way to evaluate software team quality. Learn about key steps such as using source control, creating builds efficiently, maintaining daily builds, and tracking bugs effectively. Improve your software development process with these essential practices.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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 plansfor 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/
