You are previewing 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.

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

  1. Title Page
  2. Dedication
  3. CONTENTS
  4. ABOUT THE AUTHOR
  5. ACKNOWLEDGMENTS
  6. INTRODUCTION
    1. Ah, So, You've Seen My Website...
  7. part one: Bits and Bytes: The Practice of Programming
    1. one: CHOOSING A LANGUAGE
      1. What's the Point?
    2. two: BACK TO BASICS
    3. three: THE JOEL TEST: 12 STEPS TO BETTER CODE
      1. 1. Do you use source control?
      2. 2. Can you make a build in one step?
      3. 3. Do you make daily builds?
      4. 4. Do you have a bug database?
      5. 5. Do you fix bugs before writing new code?
      6. 6. Do you have an up-to-date schedule?
      7. 7. Do you have a spec?
      8. 8. Do programmers have quiet working conditions?
      9. 9. Do you use the best tools money can buy?
      10. 10. Do you have testers?
      11. 11. Do new candidates write code during their interview?
      12. 12. Do you do hallway usability testing?
      13. Four Ways to Use The Joel Test
      14. Postscript: June 14, 2004
    4. four: THE ABSOLUTE MINIMUM EVERY SOFTWARE DEVELOPER ABSOLUTELY, POSITIVELY MUST KNOW ABOUT UNICODE AND CHARACTER SETS (NO EXCUSES!)
      1. A Historical Perspective
      2. Unicode
      3. Encodings
      4. The Single Most Important Fact About Encodings
    5. five: PAINLESS FUNCTIONAL SPECIFICATIONS PART 1: WHY BOTHER?
    6. six: PAINLESS FUNCTIONAL SPECIFICATIONS PART 2: WHAT'S A SPEC?
      1. Overview
      2. Scenarios
      3. Nongoals
      4. WhatTimeIsIt.com Flowchart
      5. Screen-by-Screen Specification
      6. Splash Screen
      7. Home Page
      8. Log In Form
    7. seven: PAINLESS FUNCTIONAL SPECIFICATIONS PART 3: BUT...HOW?
      1. Who Writes Specs?
      2. How Do You Hire a Program Manager?
    8. eight: PAINLESS FUNCTIONAL SPECIFICATIONS PART 4: TIPS
      1. Rule 1: Be Funny
      2. Rule 2: Writing a Spec Is Like Writing Code for a Brain to Execute
      3. Rule 3: Write as Simply as Possible
      4. Rule 4: Review and Reread Several Times
      5. Rule 5: Templates Considered Harmful
    9. nine: PAINLESS SOFTWARE SCHEDULES
      1. 1. Use Microsoft Excel.
      2. 2. Keep it simple.
      3. 3. Each feature should consist of several tasks.
      4. 4. Only the programmer who is going to write the code can schedule it.
      5. 5. Pick very fine-grained tasks.
      6. 6. Keep track of the original and current estimate.
      7. 7. Update the elapsed column every day.
      8. 8. Put in line items for vacations, holidays, etc.
      9. 9. Put debugging time into the schedule!
      10. 10. Put integration time into the schedule.
      11. 11. Put buffer into the schedule.
      12. 12. Never, ever let managers tell programmers to reduce an estimate.
      13. 13. A schedule is like wood blocks.
    10. ten: DAILY BUILDS ARE YOUR FRIEND
    11. eleven: HARD-ASSED BUG FIXIN'
      1. 1. Make sure you find out about the bugs.
      2. 2. Make sure you get economic feedback.
      3. 3. Figure out what it's worth to you to fix them all.
      4. Please Don't Beat Me Up!
    12. twelve: FIVE WORLDS
      1. 1. Shrinkwrap
      2. 2. Internal
      3. 3. Embedded
      4. 4. Games
      5. 5. Throwaway
      6. Know Your World
    13. thirteen: PAPER PROTOTYPING
    14. fourteen: DON'T LET ARCHITECTURE ASTRONAUTS SCARE YOU
    15. fifteen: FIRE AND MOTION
    16. sixteen: CRAFTSMANSHIP
    17. seventeen: THREE WRONG IDEAS FROM COMPUTER SCIENCE
      1. Searching
      2. Antialiased Text
      3. Network Transparency
    18. eighteen: BICULTURALISM
    19. nineteen: GET CRASH REPORTS FROM USERS—AUTOMATICALLY!
      1. Collecting Data
      2. Phoning Home
      3. Identifying Duplicate Crashes
      4. Debugging
      5. Triage
      6. Is This for You?
      7. Handling Crashes
  8. part two: Managing Developers
    1. twenty: THE GUERILLA GUIDE TO INTERVIEWING
      1. What to Ask
      2. What Not to Ask
    2. twenty-one: INCENTIVE PAY CONSIDERED HARMFUL
    3. twenty-two: TOP FIVE (WRONG) REASONS YOU DON'T HAVE TESTERS
      1. 1. Bugs come from lazy programmers.
      2. 2. My software is on the Web. I can fix bugs in a second.
      3. 3. My customers will test the software for me.
      4. 4. Anybody qualified to be a good tester doesn't want to work as a tester.
      5. 5. I can't afford testers!
    4. twenty-three: HUMAN TASK SWITCHES CONSIDERED HARMFUL
    5. twenty-four: THINGS YOU SHOULD NEVER DO, PART ONE
      1. Postscript
    6. twenty-five: THE ICEBERG SECRET, REVEALED
      1. Important Corollary One
      2. Important Corollary Two
      3. Important Corollary Three
      4. Important Corollary Four
      5. Important Corollary Five
      6. Manage the Iceberg
    7. twenty-six: THE LAW OF LEAKY ABSTRACTIONS
    8. twenty-seven: LORD PALMERSTON ON PROGRAMMING
    9. twenty-eight: MEASUREMENT
  9. part three: Being Joel: Random Thoughts on Not-So-Random Topics
    1. twenty-nine: RICK CHAPMAN IS IN SEARCH OF STUPIDITY
    2. thirty: WHAT IS THE WORK OF DOGS IN THIS COUNTRY?
    3. thirty-one: GETTING THINGS DONE WHEN YOU'RE ONLY A GRUNT
      1. Strategy 1: Just Do It
      2. Strategy 2: Harness the Power of Viral Marketing
      3. Strategy 3: Create a Pocket of Excellence
      4. Strategy 4: Neutralize the Bozos
      5. Strategy 5: Get Away from Interruptions
      6. Strategy 6: Become Invaluable
    4. thirty-two: TWO STORIES
    5. thirty-three: BIG MACS VS. THE NAKED CHEF
    6. thirty-four: NOTHING IS AS SIMPLE AS IT SEEMS
    7. thirty-five: IN DEFENSE OF NOT-INVENTED-HERE SYNDROME
    8. thirty-six: STRATEGY LETTER I: BEN & JERRY'S VS. AMAZON
      1. The Worst Thing You Can Do
    9. thirty-seven: STRATEGY LETTER II: CHICKEN-AND-EGG PROBLEMS
    10. thirty-eight: STRATEGY LETTER III: LET ME GO BACK!
    11. thirty-nine: STRATEGY LETTER IV: BLOATWARE AND THE 80/20 MYTH
    12. forty: STRATEGY LETTER V: THE ECONOMICS OF OPEN SOURCE
      1. Headline: IBM Spends Millions to Develop Open Source Software
      2. Headline: Netscape Open Sources Their Web Browser
      3. Headline: Transmeta Hires Linus, Pays Him to Hack on Linux
      4. Headline: Sun and HP Pay Ximian to Hack on Gnome
      5. Headline: Sun Develops Java; New "Bytecode" System Means Write Once, Run Anywhere
    13. forty-one: A WEEK OF MURPHY'S LAW GONE WILD
      1. Chapter One
      2. Chapter Two
      3. Chapter Three
    14. forty-two: HOW MICROSOFT LOST THE API WAR
      1. Developers, Developers, Developers, Developers
      2. Why Apple and Sun Can't Sell Computers
      3. The Two Forces at Microsoft
      4. Microsoft Lost the Backward Compatibility Religion
      5. Automatic Transmissions Win the Day
      6. One Runtime to Rule Them All
      7. Oh, Wait, There's More Coming!
      8. It's Not 1990
      9. Enter the Web
      10. I'm a Little Bit Sad About This, Myself
  10. part four: A Little Bit Too Much Commentary on .NET
    1. forty-three: MICROSOFT GOES BONKERS
      1. The Scary Thing Is, They're Earnest
      2. The Bright Side of the "Vision Thing"
    2. forty-four: OUR .NET STRATEGY
    3. forty-five: PLEASE SIR MAY I HAVE A LINKER?
  11. part five: Appendix
    1. appendix: THE BEST OF ASK JOEL
  12. INDEX
O'Reilly logo

fourteenDON'T LET ARCHITECTURE ASTRONAUTS SCARE YOU

SATURDAY, APRIL 21, 2001

When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there's a general pattern: sending files. That's one level of abstraction already. Then they go up one more level: People send files, but web browsers also "send" requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It's the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging ...

The best content for your career. Discover unlimited learning on demand for around $1/day.