Debugging Applications for Microsoft .NET and Microsoft Windows by John Robbins

1
Debugging Applications for Microsoft .NET and
Microsoft Windows by John Robbins

• Chapter 1
• Presented By Malavika Jayasimha

2
Contents at a glance

• Purpose of the book
• BUGS Where they come from and how you solve
  them
• How costly are bugs?
• Definition and classification of bugs
• Reasons for Bugs
• Planning for debugging
• Prerequisites to debugging and learning the skill
  set
• The Debugging Process
• The Debugging Secret
• Code Reviews

3
Purpose of the book

• Learn how to write applications with fewer bugs,
  thus improving code quality.
• When required to debug, one can debug much
  faster.
• Testers and Managers work more efficiently while
  handling a project.
• Most teams spend an average of 50 of their
  development cycle debugging.

4
BUGS Where They Come From And How You Solve Them

• Bugs help you learn the most about how things
  work.
• Reasons why software is so bug-prone
• New and somewhat immature branch of engineering.
• Users have come to accept bugs, particularly in
  PC software.

5
What do bugs cost you?

• In the short term, a company needs to provide
  customer support for its products, thus forcing
  it to spend time and money on maintenance.
• In the long run, customers begin looking at other
  software products that are less bug prone.

6
Definition of bugs and its classification

• Anything that causes a user pain is a bug.
• They are broadly classified into
• Inconsistent User Interfaces
• Unmet Expectations
• Poor performance
• Crashes or Data Corruption

7
Type 1 Inconsistent user interfaces

• Though not serious, quite annoying.
• All Windows based applications generally have the
  same behavior, thus making them more successful.
• Recommended books
• Microsoft Windows User Experience (MS Press
  1999). Also on the web _at_ http//msdn.microsoft.c
  om/library/en-us/dnwue/html/welcome.asp
• Designing Web Usability The practice of
  simplicity by Jacob Nielsen.
• Dont make me think! A common sense approach to
  web usability by Steve Krug.
• http//www.cnn.com as the role model website.

8
Type 2 Unmet Expectations

• This bug usually occurs at the beginning of a
  project during the requirements gathering phase.
• The cause
• A basic communication problem, and a lack of
  sufficient research on the customers real needs.
• Another cause is where the user expectations are
  higher than what the product actually delivers.
• Typical scenario is where the developers are not
  exposed to the users needs directly, but via
  their managers.

9
Type Unmet Expectations contd.

• The solution
• All members of the engineering team should visit
  the clients.
• Engineers should also oversee all support calls
  and support emails. This unfiltered feedback is
  essential for the developers.
• Never promise what you cannot deliver.

10
Type Poor Performance

• Most applications fail under real world
  circumstances, when having to deal with large
  volumes of data.
• The cause is lack of sufficient testing with
  volumes of data approaching the real world.
• The solution
• Determine the applications performance
  requirements upfront.
• Keep that as the baseline performance goal,
  against which you can measure the applications
  actual performance.

11
Type Crashes or Data Corruption

• These are the most common and severe type of
  bugs.
• This book describes in detail on how to avoid and
  debug such bugs.
• Memory leaks come in this category as well.
• Never ship a product or submit a project if
  it has this bug!

12
Reasons for Bugs

• The reasons for bugs fall into the following
  categories
• Short/stringent/impossible deadlines
• CFTL attitude
• Misunderstood requirements
• Ignorance of engineer or lack of training
• Lack of commitment to quality

13
Reason 1 Short/stringent/impossible deadlines

• Engineers work estimates are usually the basis
  of a schedule that the managers come up with.
• The causes are
• Engineers usually underestimate how long it will
  take them to develop a solid product.
• Another big mistake that both managers and
  engineers make is that they dont take into
  account the learning time to make a feature
  happen.

14
Reason 1 Short/stringent/impossible deadlines
contd.

• The result is that either the product is shipped
  late to meet all the requirements, or you will
  have to cut some of the promised product features
  to ship it on time.
• The solution
• Developers should be honest about the time they
  need to implement a feature.
• Base the ship date on the feature set.
• If the company finds the ship date unacceptable,
  then cut the features or move up the ship date.
  Resolve this issue upfront.
• Motivate the entire team to agree upon the
  decided schedule.

15
Reason 2 Code First Think Later approach

• A very common situation where the team starts
  programming before they start thinking.
• The cause
• Improper planning at every stage in the software
  cycle, especially in the requirements and design
  stages.
• Lack of proper documentation.

16
Reason 2 Code First Think Later approach contd.

• The result is that without documentation, instead
  of thinking about how to avoid bugs, the
  developer starts to work around the existing bug
  by patching up the code thus introducing more
  bugs into an already unstable code base.
• The solution is to plan the projects completely
  at every stage. Find all areas of doubt and
  confusion and address all possible issues at the
  early stages itself.

17
Reason 3 Misunderstood Requirements

• Due to a misunderstanding of requirements,
  developers either do not develop the correct
  feature, or they tend to add extra features,
  leading to more bugs.
• Companies usually dont spend enough time on
  their engineers to explain the problem domain
  clearly.
• The solution
• Have companies educate their engineers well about
  the problem domain.
• Engineers must be committed to learning the
  domain as well.
• Once the products requirements are understood
  thoroughly, plan the project well, by hashing out
  every possible detail before you begin to code.

18
Reason 3 Misunderstood Requirements contd.

• Engineers must strive to solve a problem, as
  opposed to just enable a solution.
• Some books on requirements gathering and project
  planning
• Rapid Development by Steve McConnell (MS Press
  1996).
• Under Pressure and On Time by Ed Sullivan (MS
  Press 2001).
• Dynamics of Software Development by Jim
  McCarthy (MS Press 1995).

19
Reason 4 Engineer ignorance or Improper training

• A significant cause of bugs result from the fact
  that developers do not understand the operating
  system, the language or the technology that their
  projects use.
• As a result, there is a huge possibility of
  misusing or not using the advantages of a
  language or technology.

20
Reason 4 Engineer ignorance or Improper training
contd.

• The solution is that engineers need to honest
  about their deficiencies and their true skill
  sets.
• Based on this, managers can effectively
  distribute the work, so that each one gets to do
  what they are best at.
• With this information, managers can also train
  the engineers in their areas of weakness.

21
Reason 5 Lack of commitment to quality

• Developers who are really committed to quality
  spend the effort on all parts of development, not
  just coding.
• Characteristics of good quality include
• Careful upfront planning
• Personal accountability
• Solid quality control
• Excellent communication skills

22
Reason 5 Lack of commitment to quality contd.

• Tip to ensure quality is to make sure that at
  every milestone, the product does not ship until
  every person on the team is fully satisfied.
• Record every bug before the customer makes a note
  of it!
• If you are a manager, set the direction and tone
  of the engineers. If you are an engineer, work
  towards making your code more robust and
  extensible.

23
Planning for Debugging

• I dont consider debugging as a separate step,
  but as an integral part of the entire product
  cycle. I believe you need to start debugging in
  the requirements phase and continue through to
  the final release to manufacturing
• The key points are
• The more planning upfront, the better.
• In case you need to change your code to implement
  a new feature, you need to determine and plan for
  exactly what will change.
• The cost to fixing a bug rises exponentially with
  each stage of the development cycle. Just as is
  with adding/removing features.
• Plan for testing while you plan for debugging.
• Have in-built debugging code in your application
  itself.

24
Prerequisites to Debugging

• A good debugger is a good developer and
  vice-versa.
• The following are areas in which one must be
  proficient to be a good debugger
• Know your project well
• Know your language
• Know your technology/tools
• Know your operating system/environment
• Know your CPU

25
Skill 1 Know your project

• This is the first line of defense for user
  interface, logic and performance bugs.
• Knowing how and where the features are
  implemented in the source files, you can narrow
  down to who is doing what to which part of the
  code.
• The only way to read about the project is to read
  the design documents, and architectural reports
  with UML diagrams that communicate very
  effectively how all the parts of the project are
  correlated. After this, one must walk through the
  code in the debugger for a detailed understanding.

26
Skill 2 Know your language

• It is very essential for a developer to know what
  his language does behind the scenes, apart from
  knowing how to program in it.
• Most bugs, especially those related to
  performance issues can be solved by an in-depth
  knowledge of the language.

27
Skill 3 Know your technology/tools

• To solve the harder bugs, one must know more than
  the project or the language. One must know the
  technology that the project is implemented in.
• In addition, it is also vital to know the
  advanced features of the debugging tools and any
  other tools that the developer may be using. This
  enables efficient and quick debugging.

28
Skill 4 Knowing your operating system/environment

• This can make a big difference especially while
  solving bugs that appear on some operating
  systems and not on others.
• Many bugs appear when the operating system or
  environment is misused.

29
Skill 5 Knowing your CPU

• Finally, in order to understand and debug
  assembly code, one must understand the CPU and
  basic assembly language.
• Most crashes do not occur at the source code, but
  drop into the Disassembly window. This is where
  your knowledge of assembly code will help you
  debug it.

30
Learning the Skill Set

• Reading books like
• Code Complete by Steve McConnell (MS Press
  1993).
• The practice of programming by Brian W
  Kernighan and Rob Pike (Addison Wesley 1999).
• Writing Solid Code by Steve Maguire (MS Press
  1993).
• Reading magazines.
• Coding, coding and more coding.
• Debugging and more debugging.
• Reading others code.

31
The Debugging Process

• There are 9 steps to the debugging process
• Duplicate the bug
• Describe the bug
• Always assume that the bug is yours
• Divide and Conquer
• Think Creatively
• Leverage tools
• Start heaving debugging
• Verify that the bug is fixed
• Learn and share

32
The Debugging Process

• Step 1 and Step 2 are essential in the process
  and must always be done in that order. A fix may
  be found anywhere between steps 3 and 7,in which
  case you can directly move to step 8 to verify
  and test the fix.

Duplicate the Bug
Describe the Bug
Assume bug is yours
Divide and conquer
Formulate New hypothesis
Apply Fix
Think Creatively
Leverage Tools
Start Heavy debugging
Verify the bug fix
Learn and share
33
Step 1 Duplicate the bug

• This is the most critical step. If you cannot
  duplicate it, in all probability, you cannot
  eliminate it.
• Write down the steps that lead you to the bug.
• Once you duplicate the bug, see if there are
  others paths through which you can get to the
  same bug. This gives a better sense of the data
  and boundary conditions that are causing the
  problem.
• Document each trial all along the way. This is
  specially helpful in situations where you may not
  be able to duplicate a bug successfully.

34
Step 2 Describing the bug

• Always be as correctly descriptive as you can
  about the bug.
• This helps other engineers to look at your bug in
  a different light.
• A good description most often helps fix the bug.

35
Step 3 Always assume the bug is yours

• The odds are excellent that the bug is in your
  source code.
• At least you can fix it if it is in your source
  code. If it is in your compiler or environment,
  thats a bigger issue!

36
Step 4 Divide and Conquer

• Once you have duplicated and described the bug,
  you have an idea of where it is.
• The next step is to confirm your suspicion.
• Read the source code and check what the code
  really does and compare it to what it should do.
• Work through the various scenarios that will help
  you box the buggy section of code.
• If your hypothesis was wrong, then reassess it,
  and start over. This way, you eliminate more and
  more code till you wind up with the buggy
  section.
• Update the bug record to reflect the new
  hypothesis.

37
Step 5 Think Creatively

• While trying to eliminate a bug that occurs only
  on certain machines and not on others, start
  looking at the bug from different perspectives.
  Open up your mind to the various possibilities,
  like version mismatches, OS differences,
  installation problems and other external causes.
• Clear your mind to get a broader perspective.
• Talk to a person who is relatively new to your
  problem.
• Diagrams help!!

38
Step 6 Leverage Tools

• Use the tools that are available for debugging.
• This not only helps you save time and money, but
  also helps you keep your customers in the long
  run!
• Some typical tools used
• Error Detection Tool used for invalid memory
  access, memory and resource leaks etc. (e.g..,
  NuMegas BoundsChecker).
• Performance Tool helps you track down where your
  application is slow. (e.g., NuMegas TrueTime).
• Code coverage tool shows the source code lines
  that are not executed when you run your program.
  (e.g., NuMegas TrueCoverage).

39
Step 7 Start Heavy Debugging

• If by this step, you have not been able to fix
  the bug, then its time to explore your programs
  operation in good detail.
• It is at this stage that you want to use the
  debuggers advanced features.
• Always have an idea/hypothesis of what and where
  the bug is likely to be before using the
  debugger.
• Spend your debugging in that section of the code
  only. Do not randomly start using the debugger
  without any idea of what might be causing the
  problem and where it is most likely present.
• While you make changes to fix the bug,
  simultaneously check if it works under normal
  conditions.

40
Step 8 Verify that the bug is fixed

• When the bug is fixed, the next step is to verify
  the fix by testing time and again to make sure it
  works under all possible conditions good and
  bad.
• If it is a fix in a critical module, all team
  members should be notified, and it must be tested
  for ripple effects.

41
Step 9 Learn and Share

• Learn from the bugs you have fixed.
• Make sure it is well-documented for future
  reference.
• Sharing it with colleagues helps them the next
  time they encounter a similar bug.

42
The Debugging Secret

• Have a hypothesis ready before ever firing up the
  debugger. This ensures a purpose for using the
  debugger and is of immense help in fixing the bug
  quickly.

43
Code Reviews

• Should we do them?
• Certainly. This is an important aspect of the
  software cycle that is very close to debugging.
• The best way to do a code review by your
  colleague is to read your code line by line, with
  the developer, keeping in mind all the inputs and
  outputs as you go by each line of code.
• This helps you focus on what the code really does.

44
Thank you!