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 Chapter 1

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 Chapter 1

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. Chapter 1

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. Chapter 1

5. What do bugs cost you? • In the short term, a company needs to provide customer support for it’s 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. Chapter 1

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 Chapter 1

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 @: http://msdn.microsoft.com/library/en-us/dnwue/html/welcome.asp • “Designing Web Usability: The practice of simplicity” by Jacob Nielsen. • “Don’t make me think! A common sense approach to web usability” by Steve Krug. • http://www.cnn.com as the role model website. Chapter 1

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 customer’s 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. Chapter 1

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. Chapter 1

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 application’s performance requirements upfront. • Keep that as the baseline performance goal, against which you can measure the application’s actual performance. Chapter 1

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! Chapter 1

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 Chapter 1

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 don’t take into account the learning time to make a feature happen. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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 don’t 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. Chapter 1

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). Chapter 1

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. Chapter 1

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 area’s of weakness. Chapter 1

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 Chapter 1

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. Chapter 1

23. Planning for Debugging • “I don’t 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. Chapter 1

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 Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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 Chapter 1

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 Chapter 1

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. Chapter 1

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. Chapter 1

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, that’s a bigger issue! Chapter 1

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. Chapter 1

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!! Chapter 1

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.., NuMega’s BoundsChecker). • Performance Tool helps you track down where your application is slow. (e.g., NuMega’s TrueTime). • Code coverage tool shows the source code lines that are not executed when you run your program. (e.g., NuMega’s TrueCoverage). Chapter 1

39. Step 7: Start Heavy Debugging • If by this step, you have not been able to fix the bug, then it’s time to explore your programs’ operation in good detail. • It is at this stage that you want to use the debugger’s 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. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

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. Chapter 1

44. Thank you! Chapter 1