Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Introduction and Chapter 5

The author talks about integrating testing into development process using the techniques of test-driven-development and refactoring. The author discusses different kinds of testing such as:

• Unit Testing
• Integration Testing
• System Testing
• Stress Testing
• Beta Testing
• Acceptance Testing

The author then provides a typical set of steps followed by developers in a team and suggests to have system testing done by somebody other than the one who has written the code.

The author provides a list of unit testing tools available. The author then uses one of the tools and write unit test cases for his Download Tracker application. The author then discusses Test Driven Development and provides two easy steps followed in the process:

• Write a failing automated test before any code
• Remove duplication

The author then applies the methodology to his own Download Tracker application to provide example.

The author then introduces the concept of refactoring, the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure. The author then provides a list of tools that can be used for automated refactoring.

Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Introduction and Chapter 4

The author talks about defensive coding in this chapter whose goal is to write code that makes it easy to find problems and make modifications.

The author discuss about usage of assertions to detect errors in code. The author provides following two guidelines:

• Assertions should not have side effects.
• Avoid assertions to test compiler/language issues

The author then talks about exceptions, the exception mechanism in C#, the reason for creating custom exceptions and the guidelines for creating custom exceptions in C#. The author then implements his own custom exception for Download Tracker application. The author then provides following guidelines for good exceptions:

• Exceptions are for exceptional situations
• Don't create unnecessary custom exceptions
• Constructors with a string value should be used
• Pass exception from low level routine to higher level routine with enough information

The author then examines the debate of whether to use comments or have self-documenting code. The author likes the first approach better and classifies comments in following different categories:

1. Noise comments: They just repeat what the code says and does not increase the readability and should be avoided.
2. Placeholder comments: They are note to your future self.
3. Summary and Intent comments: Summary comments summarize a lot of code in short English statements. Intent comments do not explain what the code does, it explains why it does it in a particular manner.

Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Introduction and Chapter 3

In this chapter the author talks about how to use source code control tool effectively. The author provides following list of commands for a novice user to learn:

• Create Project
• Add
• Get
• Checkout
• Revert
• Check In

The author then enlists following commands for level 2 user:

• Label
• Merge
• Branch
• Share

The author then specifies following commands to be used by an expert user:

• Cloak
• Delete
• Move
• Rename
• Pin
• Rollback

The author then specifies a list of source code control tools and their pros and cons. The author provides following list of characteristics to look at when deciding on a source-code control system:

• Price
• Concurrent Development Style (checkout-edit-checkin vs edit-merge-commit).
• Repository
• Internet Friendliness
• IDE Integration
• Cross-platform support

The author then talks about best practices that needs to be followed including:

• What to put under source code control
• Checking out as less files as possible
• Putting comments at the time of check-in
• Proper use of labels
• Maintaining discipline in branching
• Integrate bug-tracking tool with source code control tool

The author then provides the source code control created for his Download Tracker tool.

Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Chapter 2

The author talks about how to organize project in three different ways:

• Architectural perspective addresses the overall shape of the application
• Project perspective addresses the construction of the application
• The staged delivery perspective addresses the release of the application

The author then provides definition of architecture with two common elements:

1. Highest level breakdown of a system into parts
2. Decisions that are hard to change

The author then provides three stages of software construction:

1. Architectural stage involves important decisions
2. Design stage involves detailed plans for writing the application
3. Implementation stage involves writing code

The author then draws architecture of its Download Tracker application. The author then talks about UML and tools that can be used to model architecture in form of UML.

The author talks about design patterns and how they help at architecture level. The author then talks about three methods of coding a large project:

1. Breadth-First: In this method, the entire skeleton of the application is built without any details. The author enlists following advantages and disadvantages of the approach:
• This method ensures that everything in architecture is covered.
• It demonstrates overall flow of application early in coding cycle.
• Looking at the skeleton, customer's expectation for schedule may become unrealistic.
• A team of developers are difficult to manage in this approach.
2. Depth-First: In this approach, one part of the application is completely developed before moving on to anything else. The author enlists following advantages and disadvantages for the approach:
• The developer can focus on just one piece of code for its issues.
• A team of developers can work on separate components.
• Architecture will not be tested till late in the development cycle.
• The complete application flow cannot be determined till the end of the development.
  
3. Mixed Models: The author suggests to take a mixed approach since most products have some UI component which can be developed using breadth-first approach and the rest of the components can be developed using depth-first approach.
   

The author then talks about three cornered trade-off representing product, cost and time. The author then discusses several approaches such as:

• The Beta-Test approach: This is used by Microsoft where there are several targets like
  
• Alpha
• Beta 1
• Beta 2
• Release Candidate
• Release
• The XP approach: This involves making a series of small releases with high quality bar. Releases are spaced close to one another with very small functionality added above the previous release.

The author emphasizes the fact that product in three cornered trade-off represents not just features but quality too. Releasing a product full of bugs is a sure-shot way to lose customers.

Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Introduction and Chapter 1

Introduction

The author distinguishes between coders, who know syntax and semantics of computer language and developers, who can apply that knowledge to turning out a working application with all the supporting details. The book is targetted to help a coder become a developer.

The author then provides an outline of how the book is organized into a sensible order of chapters so that the reader completes the task to ship a successful software product although every chapter is organized as a stand alone one.

Chapter 1
The author emphasizes on requirements management and choosing a methodology before starting to write a single line of code. The author then provides a list of questions to do brainstorming to start software development process. The author then discusses two concepts:

• The elevator pitch: The idea was popularized in dot-com era when instead of 15-minute presentation, entrepreneurs were told to explain their ideas to a VC in an elevator ride to 87th floor in 30-seconds. Based on this, the author provides a rule to write a short statement describing what the software will do and why. The author warns the developer to refrain away from feature creep - the continuing addition of new functionality when the old ones are still being coded. The author provides some points to keep in mind while coming up with elevator pitch and creates one for his own software.
  
• The mind map: Mind-map is a form of diagram for free-form brainstorming. The author then provides a list of softwares to use mind-map on Windows. The author also provides mind-map of the software he is going to create in the book called Document Tracker.

The author then classifies the requirements in four sets:

• Business requirements: These are high-level objectives of the organization.
• User requirements: The goals the user must be able to perform.
  
• Functional requirements: Software functionality that must be built for the user to accomplish their tasks.
• System requirements:

The author then provides a checklist to help elicit requirements at the time of working with external customer. The author then discuss about ways to capture requirements and describes use case as one of them. The author then enlists use cases of the tool Document Tracker. The author then provides a list of items that should be present in the use case document.

Instead of focusing on major milestones, the author advises the developers and managers to focus on small tasks, e.g. instead of defining a target date for user interface, set target date for individual dialog boxes and forms. The author then provides some examples of project tracking and billing tools.

The author provides a list of issues in using Microsoft Project for software project management such as it is overkill, designed for huge software projects etc... The author then talks about different methodologies of software development such as:

1. Waterfall Approach: The method is like a waterfall which starts from requirements analysis and then flow downhill through preliminary design, detailed design, implementation and system testing and acceptance testing.
2. Iterative Approach: All the project phases like development testing and planning are repeated many times in the course of the project. The author provides two examples Rational Unified Process (RUP) and Microsoft Solutions Framework (MSF) of iterative approaches.
   
3. Agile Approach: The author lists methodologies such as Extreme Programming (XP), Scrum, and Crystal for rapid application development.

The author finally recommends to use what works and leave the rest. Both waterfall and iterative approaches measure the cost of an entire project upfront while agile methodologies keep delivering small chunks until time or money runs out. The author also mentions test-driven-development method which resulted from extreme programming.

The author then provides a checklist while planning the software to make sure you are building the right thing.

The Art of Software Testing by Glenford Myers : My Opinion

I would give this book 5 out of 5. It is a must read book for both programmers and quality assurance engineers. It should be included in colleges as a textbook along with Code Complete that I described earlier.
To make it easy to browse, I am putting links to all the chapters below:

• Preface
• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 4
• Chapter 5
• Chapter 6
• Chapter 7
• Chapter 8

The Art of Software Testing by Glenford Myers : Chapter 8

The author discusses about testing tools and other techniques in this chapter. The test case design has not been automated but significant advancements have been made in automating other aspects of the testing process. Some of the tools are:

• Module driver tools: It provides a language to express test cases to test a module. The author mentions three advantages of such tool:
1. The language reduces the effort required and standardizes the form of test cases.
2. Rerun of test cases is easy when a correction is made to the module
3. The automatic verification of results forces the programmer to state explicitly the expected output.
• The author mentions AUT (Automated Unit Test), MTS and TESTMASTER as examples.
  
• Static flow analysis tools: They analyze control flow and data flow of the program, they can detect following errors:
• Variable with an undefined value
• Variables with assigned values that are never used
• Unreachable code
• Inconsistent interfaces among modules
• ACES, FACES, AUDIT, RXVP and DAVE are examples of this kind of tools.
• Test coverage monitors: Coverage monitors are tools that monitor the subject program during execution to provide statistics to determine whether the statement-coverage and decision-coverage criteria have been met.
• Mathematical proof of program correctness: The proof of program correctness tries to demonstrate that the program is error free. The author provides references to method of inductive assertions, predicate transformers, subgoal induction, computation induction, structural induction and intermittent assertions.
• Program correctness provers: The goal is to create a program that, takes as input another program and its input and output assertions, attempt to prove the subject program correct.
• Symbolic Execution: It is a hybrid between program testing and correctness provers. The subject program is executed symbolically. 
• Test Data Generators: The author talks about several tools that generate test data to meet a specific criterion by analyzing a program's logic flow.
• Environmental Simulators: These are useful when testing in actual environment cannot be done, test conditions are hard to create in real environment etc...
• Sneak Circuit Analysis: 
• Virtual Machines: They provide multiple programs impression that each is executing in separate standalone machine.
• Testing Mathematical Software: 
• Interactive Debugging Tools: The author discuss about EXDAMS, ISMS and CAPS.
• Compiler Debugging Aids: Compilers can contain debugging features added to the language such as
• Ability to designate any arbitrary statements as debugging statements and to activate and deactivate at compilation or run time.
  
• Program State Monitors: It monitors a program during execution, watching for the arrival of a certain predefined conditions and/or collecting data that would be useful during debugging such as first, last, minimum and maximum of each assignment statement, minimum and maximum values of each do-loop control variable etc...
  

The author then discusses about software error studies, software error data-collection and predictive models.  The author then provides some statistics on testing experiments and the results. The author then provides some findings on debugging experiments.

The author discusses how computer architecture or hardware design can help debugging by providing features not present in the current computer design.

The Art of Software Testing by Glenford Myers : Chapter 7

Debugging is defined as determining the exact nature and location of the suspected error within the program and fixing or repairing the error.

The author then discusses debugging methods:

1. Brute-force debugging: It is the most inefficient and unsuccessful method and advises to use this only when all other method fails. The author discusses three methods of brute-force debugging.
• Debugging with a storage dump: This is the most efficient method and the author provides a list of problems associated with this method including static nature of the dump, massive amounts of irrelevant data, etc...
  
• Debugging with scattered print statements: The author also enlists the shortcomings of this technique such as massive amount of data, require to change program, etc...
• Debugging with automated debugging tools: The author compares debugging with solving a homicide and emphasizes the use of brain over a set of aids.
  
2. Debugging by Induction: The author provides steps in the induction process as follows:
• Locate the pertinent data
• Organize the data
• Find relationship among data
• Devise a hypothesis
• Prove the hypothesis
3. Debugging by Deduction: The author provides steps in the deduction process as follows:
• Enumerate the possible causes
• Use the data to eliminate the possible causes
• Refine the remaining hypothesis
• Prove the remaining hypothesis
4. Debugging by Backtracking: In this method, mental reverse execution of the program is performed in which values of variables and state of the program is deduced by looking at the wrong output and the process is continued till the origin of the first unexpected state.
   
5. Debugging by Testing: Separate set of "slim" test cases are developed to provide information useful in locating a suspected error.

The author then provides two set of principles:

1. Error locating principles
2. Error repairing principles
• When there is one bug, there is likely to be another.
• Fix the error, not just the symptom of it.
• The probability of fix being correct is not 100%.
• The probability of the fix being correct drops as the size of the program grows.
• Beware of the possibility that an error correction creates a new error.
• The process of error repair should put one back temporarily in design phase.
• Change the source code, not the object code.

The author then discusses about improvement that can be achieved by careful analysis of software errors:

1. When was the error made?
2. Who made the error?
3. What was done incorrectly?
4. How could the error have be prevented?
5. Why wasn't the error detected earlier?
6. How could the error have been detected earlier?
7. How was the error found?