Joel on Software · And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity by Spolsky, Joel -- Read -- Imperial Library of Trantor

Index

Cover Page Title Page Copy Right Dedication Contents About the Author Acknowledgement Introduction part one Bits and Bytes: The Practice of Programming

one CHOOSING A LANGUAGE

What's the Point?

two BACK TO BASICS three THE JOEL TEST: 12 STEPS TO BETTER CODE

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? Four Ways to Use The Joel Test Postscript: June 14, 2004

four THE ABSOLUTE MINIMUM EVERY SOFTWARE DEVELOPER ABSOLUTELY, POSITIVELY MUST KNOW ABOUT UNICODE AND CHARACTER SETS (NO EXCUSES!)

A Historical Perspective Unicode Encodings The Single Most Important Fact About Encodings

five PAINLESS FUNCTIONAL SPECIFICATIONS PART 1: WHY BOTHER? six PAINLESS FUNCTIONAL SPECIFICATIONS PART 2: WHAT'S A SPEC?

Overview Scenarios Nongoals WhatTimeIsIt.com Flowchart Screen-by-Screen Specification Splash Screen Home Page Log In Form

seven PAINLESS FUNCTIONAL SPECIFICATIONS PART 3: BUT...HOW?

Who Writes Specs? How Do You Hire a Program Manager?

eight PAINLESS FUNCTIONAL SPECIFICATIONS PART 4: TIPS

Rule 1: Be Funny Rule 2: Writing a Spec Is Like Writing Code for a Brain to Execute Rule 3: Write as Simply as Possible Rule 4: Review and Reread Several Times Rule 5: Templates Considered Harmful

nine PAINLESS SOFTWARE SCHEDULES

1. Use Microsoft Excel. 2. Keep it simple. 3. Each feature should consist of several tasks. 4. Only the programmer who is going to write the code can schedule it. 5. Pick very fine-grained tasks. 6. Keep track of the original and current estimate. 7. Update the elapsed column every day. 8. Put in line items for vacations, holidays, etc. 9. Put debugging time into the schedule! 10. Put integration time into the schedule. 11. Put buffer into the schedule. 12. Never, ever let managers tell programmers to reduce an estimate. 13. A schedule is like wood blocks.

ten DAILY BUILDS ARE YOUR FRIEND eleven HARD-ASSED BUG FIXIN'

1. Make sure you find out about the bugs. 2. Make sure you get economic feedback. 3. Figure out what it's worth to you to fix them all. Please Don't Beat Me Up!

twelve Five Worlds

1. Shrinkwrap 2. Internal 3. Embedded 4. Games 5. Throwaway Know Your World

thirteen PAPER PROTOTYPING fourteen DON'T LET ARCHITECTURE ASTRONAUTS SCARE YOU fifteen Fire and Motion sixteen CRAFTSMANSHIP seventeen THREE WRONG IDEAS FROM COMPUTER SCIENCE

Searching Antialiased Text Network Transparency

eighteen BICULTURALISM nineteen GET CRASH REPORTS FROM USERS—AUTOMATICALLY!1

Collecting Data Phoning Home Identifying Duplicate Crashes Debugging Triage Is This for You? Handling Crashes

part two Managing Developers

twenty THE GUERILLA GUIDE TO INTERVIEWING

What to Ask What Not to Ask

twenty-one INCENTIVE PAY CONSIDERED HARMFUL twenty-two TOP FIVE (WRONG) REASONS YOU DON'T HAVE TESTERS

1. Bugs come from lazy programmers. 2. My software is on the Web. I can fix bugs in a second. 3. My customers will test the software for me. 4. Anybody qualified to be a good tester doesn't want to work as a tester. 5. I can't afford testers!

twenty-three HUMAN TASK SWITCHES CONSIDERED HARMFUL twenty-four THINGS YOU SHOULD NEVER DO, PART ONE1

Postscript

twenty-five THE ICEBERG SECRET, REVEALED

Important Corollary One Important Corollary Two Important Corollary Three Important Corollary Four Important Corollary Five Manage the Iceberg

twenty-six THE LAW OF LEAKY ABSTRACTIONS twenty-seven LORD PALMERSTON ON PROGRAMMING twenty-eight MEASUREMENT

part three Being Joel: Random Thoughts on Not-So-Random Topics

twenty-nine RICK CHAPMAN IS IN SEARCH OF STUPIDITY1 thirty WHAT IS THE WORK OF DOGS IN THIS COUNTRY? thirty-one GETTING THINGS DONE WHEN YOU'RE ONLY A GRUNT

Strategy 1: Just Do It Strategy 2: Harness the Power of Viral Marketing Strategy 3: Create a Pocket of Excellence Strategy 4: Neutralize the Bozos Strategy 5: Get Away from Interruptions Strategy 6: Become Invaluable

thirty-two TWO STORIES thirty-three BIG MACS VS. THE NAKED CHEF thirty-four NOTHING IS AS SIMPLE AS IT SEEMS thirty-five IN DEFENSE OF NOT-INVENTED-HERE SYNDROME thirty-six STRATEGY LETTER I: BEN & JERRY'S VS. AMAZON

The Worst Thing You Can Do

thirty-seven STRATEGY LETTER II: CHICKEN-AND-EGG PROBLEMS thirty-eight STRATEGY LETTER III: LET ME GO BACK! thirty-nine STRATEGY LETTER IV: BLOATWARE AND THE 80/20 MYTH forty STRATEGY LETTER V: THE ECONOMICS OF OPEN SOURCE

Headline: IBM Spends Millions to Develop Open Source Software Headline: Netscape Open Sources Their Web Browser Headline: Transmeta Hires Linus, Pays Him to Hack on Linux Headline: Sun and HP Pay Ximian to Hack on Gnome Headline: Sun Develops Java; New "Bytecode" System Means Write Once, Run Anywhere

forty-one A WEEK OF MURPHY'S LAW GONE WILD

Chapter One Chapter Two Chapter Three

forty-two HOW MICROSOFT LOST THE API WAR

Developers, Developers, Developers, Developers Why Apple and Sun Can't Sell Computers The Two Forces at Microsoft Microsoft Lost the Backward Compatibility Religion Automatic Transmissions Win the Day One Runtime to Rule Them All Oh, Wait, There's More Coming! It's Not 1990 Enter the Web I'm a Little Bit Sad About This, Myself

part four A Little Bit Too Much Commentary on .NET

forty-three MICROSOFT GOES BONKERS

The Scary Thing Is, They're Earnest The Bright Side of the "Vision Thing"

forty-four OUR .NET STRATEGY forty-five PLEASE SIR MAY I HAVE A LINKER?

part five Appendix

appendix THE BEST OF ASK JOEL

Index

← Prev
Back
Next →

← Prev
Back
Next →