Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems - Softcover

Agans, David J

Softcover

ISBN 10: 0814474578 ISBN 13: 9780814474570

Verlag: Amacom, 2006

Inhaltsangabe

When the pressure is on to resolve an elusive software or hardware glitch, what’s needed is a cool head courtesy of a set of rules guaranteed to work on any system, in any circumstance.

Written in a frank but engaging style, this book provides simple, foolproof principles guaranteed to help find any bug quickly. Recognized tech expert and author David Agans changes the way you think about debugging, making those pesky problems suddenly much easier to find and fix.

Agans identifies nine simple, practical rules that are applicable to any software application or hardware system, which can help detect any bug, no matter how tricky or obscure. Illustrating the rules with real-life bug-detection war stories, Debugging shows you how to:

• Understand the system: how perceiving the ""roadmap"" can hasten your journey
• Quit thinking and look: when hands-on investigation can’t be avoided
• Isolate critical factors: why changing one element at a time can be an essential tool
• Keep an audit trail: how keeping a record of the debugging process can win the day

Whether the system or program you’re working on has been designed wrong, built wrong, or used wrong, Debugging helps you think correctly about bugs, so the problems virtually reveal themselves.

Über diesen Titel

Über die Autorin bzw. den Autor

David J. Agans is a recognized expert called in to help with tough debugging problems. He currently runs PointSource, a computer systems consultancy. He has worked with industrial control and monitoring systems, integrated circuit design, handheld PCs, videoconferencing, and countless other systems.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Debugging

The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems

By David J. Agans

AMACOM

Copyright © 2002 David J. Agans
All rights reserved.

ISBN: 978-0-8144-7457-0

Contents

Chapter 1: Introduction, 1, 
Chapter 2: The Rules—Suitable for Framing, 9, 
Chapter 3: Understand the System, 11, 
Chapter 4: Make It Fail, 25, 
Chapter 5: Quit Thinking and Look, 45, 
Chapter 6: Divide and Conquer, 67, 
Chapter 7: Change One Thing at a Time, 83, 
Chapter 8: Keep an Audit Trail, 97, 
Chapter 9: Check the Plug, 107, 
Chapter 10: Get a Fresh View, 115, 
Chapter 11: If You Didn't Fix It, It Ain't Fixed, 125, 
Chapter 12: All the Rules in One Story, 133, 
Chapter 13: Easy Exercises for the Reader, 137, 
Chapter 14: The View from the Help Desk, 157, 
Chapter 15: The Bottom Line, 171, 
Index, 177, 

CHAPTER 1

Introduction

"At present I am, as you know, fairly busy, but I propose to devote my declining years to the composition of a textbook which shall focus the whole art of detection into one volume."

—SHERLOCK HOLMES, THE ADVENTURE OF THE ABBEY GRANGE

This book tells you how to find out what's wrong with stuff, quick. It's short and fun because it has to be—if you're an engineer, you're too busy debugging to read anything more than the daily comics. Even if you're not an engineer, you often come across something that's broken, and you have to figure out how to fix it.

Now, maybe some of you never need to debug. Maybe you sold your dot.com IPO stock before the company went belly-up and you simply have your people look into the problem. Maybe you always luck out and your design just works—or, even less likely, the bug is always easy to find. But the odds are that you and all your competitors have a few hard-to-find bugs in your designs, and whoever fixes them quickest has an advantage. When you can find bugs fast, not only do you get quality products to customers quicker, you get yourself home earlier for quality time with your loved ones.

So put this book on your nightstand or in the bathroom, and in two weeks you'll be a debugging star.

How Can That Work?

How can something that's so short and easy to read be so useful? Well, in my twenty-six years of experience designing and debugging systems, I've discovered two things (more than two, if you count stuff like "the first cup of coffee into the pot contains all the caffeine"):

1. When it took us a long time to find a bug, it was because we had neglected some essential, fundamental rule; once we applied the rule, we quickly found the problem.

2. People who excelled at quick debugging inherently understood and applied these rules. Those who struggled to understand or use these rules struggled to find bugs.

I compiled a list of these essential rules; I've taught them to other engineers and watched their debugging skill and speed increase. They really, really work.

Isn't It Obvious?

As you read these rules, you may say to yourself, "But this is all so obvious." Don't be too hasty; these things are obvious (fundamentals usually are), but how they apply to a particular problem isn't always so obvious. And don't confuse obvious with easy—these rules aren't always easy to follow, and thus they're often neglected in the heat of battle.

The key is to remember them and apply them. If that was obvious and easy, I wouldn't have to keep reminding engineers to use them, and I wouldn't have a few dozen war stories about what happened when we didn't. Debuggers who naturally use these rules are hard to find. I like to ask job applicants, "What rules of thumb do you use when debugging?" It's amazing how many say, "It's an art." Great—we're going to have Picasso debugging our image-processing algorithm. The easy way and the artistic way do not find problems quickly.

This book takes these "obvious" principles and helps you remember them, understand their benefits, and know how to apply them, so you can resist the temptation to take a "shortcut" into what turns out to be a rat hole. It turns the art of debugging into a science.

Even if you're a very good debugger already, these rules will help you become even better. When an early draft of this book was reviewed by skilled debuggers, they had several comments in common: Besides teaching them one or two rules that they weren't already using (but would in the future), the book helped them crystallize the rules they already unconsciously followed. The team leaders (good debuggers rise to the top, of course) said that the book gave them the right words to transmit their skills to other members of the team.

Anyone Can Use It

Throughout the book I use the term engineer to describe the reader, but the rules can be useful to a lot of you who may not consider yourselves engineers. Certainly, this includes you if you're involved in figuring out what's wrong with a design, whether your title is engineer, programmer, technician, customer support representative, or consultant.

If you're not directly involved in debugging, but you have responsibility for people who are, you can transmit the rules to your people. You don't even have to understand the details of the systems and tools your people use—the rules are fundamental, so after reading this book, even a pointy-haired manager should be able to help his far-more-intelligent teams find problems faster.

If you're a teacher, your students will enjoy the war stories, which will give them a taste of the real world. And when they burst onto that real world, they'll have a leg up on many of their more experienced (but untrained in debugging) competitors.

It'll Debug Anything

This book is general; it's not about specific problems, specific tools, specific programming languages, or specific machines. Rather, it's about universal techniques that will help you to figure out any problem on any machine in any language using whatever tools you have. It's a whole new level of approach to the problem—for example, rather than tell you how to set the trigger on a Glitch-O-Matic digital logic analyzer, I'm going to tell you why you have to use an analyzer, even though it's a lot of trouble to hook it up.

It's also applicable to fixing all kinds of problems. Your system may have been designed wrong, built wrong, used wrong, or just plain got broken; in any case, these techniques will help you get to the heart of the problem quickly.

The methods presented here aren't even limited to engineering, although they were honed in the engineering environment. They'll help you figure out what's wrong with other things, like cars, houses, stereo equipment, plumbing, and human bodies. (There are examples in the book.) Admittedly, there are systems that resist these techniques—the economy is too complex, for example. And some systems don't need these methods; e.g., everybody already knows what's wrong with the government.

But It Won't Prevent, Certify, or Triage Anything

While this book is general about methods and systems, it's very focused on finding the causes of bugs and fixing them.

It's not about quality development processes aimed at preventing bugs in the first place, such as ISO-9000, code reviews, or risk management. If you want to read about that, I recommend books like The Tempura Method of...

Details zur Ausgabe

• Verlag: Amacom
• Erscheinungsdatum: 2006
• Sprache: Englisch
• ISBN 10: 0814474578
• ISBN 13: 9780814474570
• Einband: Taschenbuch
• Anzahl der Seiten: 200
• Kontakt zum Hersteller: HarperCollins; https://harpercollins.co.uk; ; "The News Building 1 London Bridge Street,"; London; SE1 9GF; Vereinigtes Königreich
• Verantwortliche Person: gpsr@libri.de; gpsr@libri.de; ; Friedensallee 273; Hamburg; 22763; Deutschland