Code Complete by Steve McConnell : Chapter 25

The author focuses on unit-testing in this chapter. Unit-testing is a hard activity for developers to swallow since its outcome, to find errors, is completely reverse of what other development activities try to achieve. The author then discuss a general approach to unit testing:

• Test for each relevant requirement.
• Test for each relevant design concern.
• Add test cases to those that tests the requirements and the design and data flow tests.

The author describes that it is impossible to prove that a program is correct by testing it since the number of test cases to exhaustively test even a simple program is too large.

The author suggests to use coverage monitors to make sure complete code path is covered. There are several methods to determine the set of test cases that cover complete code path including:

1. Structured Basis Testing: This involves calculating cyclomatic complexity and creating test cases based on it.
2. Data-flow Testing: The author defined different states in which data can be classified and then enlists anomalous sequences of data states.
3. Equivalence Partitioning: This involves dividing the data in partitions such that any one partition achieves what all combined achieves and redundancy is removed.
4. Error Guessing: It involves using heuristics to guess which part of the program has errors and try to create test cases for it. The author then provides kinds of errors that can be guessed.

• Boundary Analysis: Off-by-one errors are the most common bugs.
• Classes of bad data: Typical bad data set include
  
• Too much data
• Too little data
• Uninitialized data
• Invalid data
• Classes of good data: Errors can be present in processing of nominal data set too. Other good data sets worth checking are:
• Minimum normal configuration
• Maximum normal configuration
• Compatibility with old data
  

The author then provides some statistics on distribution of errors which says that 80 percent of the errors are found in 20 percent of the routines while 50 percent of the errors are found in 10 percent of the routines. The author cites a study to provide classification of errors that were detected and some suggestions:

• The scope of most errors is limited
• Many errors are outside the domain of construction
• Most implementation errors are programmer's fault
• Clerical errors are a common source of problems
• Misunderstanding the design is a common cause of programmer errors
• Avoiding errors in assignment statements is a key to quality
• Most errors are easy to fix

As mentioned previously, the proportion of construction errors in software decreases as the number of lines of code increases. The author then provides some data related to industry average figures for number of defects found in software.

The author then provides some guidelines to tackle the errors in testing itself.

The author then provides some list of tools to help in testing:

• Scaffolding
• Result comparators
• Test-data generators
• Coverage monitors
• Symbolic debuggers
• System perturbers
• Error databases
  

The author then talks about points to improve testing including planning for test, regression testing and keeping test records.

Code Complete by Steve McConnell : Chapter 24

The author focuses on importance of reviews in this chapter. The author describes the basic reason behind technical reviews: All developers have confirmation bias so they are blind to some trouble spots in their work and other people do not have the same blind spots.

The author points out that code inspection has higher effectiveness compared to software testing or unit testing and the defect discovered by reviews are different from testing.

Technical reviews help in assessing the progress and quality of the project.

The author then discuss about inspections and how they differ from other kind of reviews. The author then discuss different roles played during an inspection including:

1. Moderator
2. Author
3. Scribe
4. Reviewer
5. Management

The author emphasizes to have no less than three participants in an inspection since author, moderator and reviewer roles should be played by different people.

The author then outlines the general procedure for inspection:

1. Planning
2. Overview
3. Preparation
4. Inspection meeting
5. Inspection report
6. Rework
7. Follow-up
8. Third-hour meeting
9. Fine-tuning the inspection

The author also discusses the problem of ego arising during code-inspection. The purpose of the inspection should be to find defects and not to criticize author of the code or to debate about who is right or wrong.

The author then discusses about other kind of reviews including:

1. Walkthroughs: The author presents several things common for all walkthroughs
• The purpose of a walkthrough is to improve the quality of a program rather than assess it.
• It is a chance for senior programmers to pass on experience and corporate culture to junior programmers.
  The author then compares inspections with walkthroughs on several properties.
2. Code Reading: The author cites a study saying that more defects are discovered in code reading than in testing per hour of effort. It is different from walkthrough or review such that there is no meeting done.
3. Dog and Pony shows: The product is demonstrated to a customer.

Code Complete by Steve Mcconnell : Chapter 23

In this chapter, the author talks about software quality, in terms of external, the one that the end user experiences and internal, the one that programmers care about. The external characteristics are defined in terms of

1. Correctness
2. Usability
3. Efficiency
4. Reliability
5. Integrity
6. Adaptability
7. Accuracy
8. Robustness

The internal characteristics are defined in terms of

1. Maintainability
2. Flexibility
3. Portability
4. Reusability
5. Readability
6. Testability
7. Understandability

The author then provides a relationship table between these characteristics. Some characteristics co-operate while some conflict with each other, e.g. focussing on efficiency may compromise correctness.

The author then lists some techniques for improving software quality including:

1. Setting explicit quality objectives.
2. Have explicit quality-assurance activity.
3. Develop a testing strategy
4. Software engineering guidelines
5. Have informal technical reviews
6. Have formal technical reviews
7. External audit
8. Have effective risk management
9. Follow change control procedures
10. Measure the results of a quality assurance plan
11. Prototype
    

The author then cites a study to show that programmers work for the objectives specified, but they must be told what the objectives are.

The author then provides details of a study to determine the effectiveness of defect detection techniques e.g. review of design documents, code reviews, prototyping, unit-testing, functional testing, integration testing, etc... The author concludes that none of the methods has success rate in access of 65% thus it is required that a combination of these techniques is used instead of just one technique alone.

The author cites studies that shows that inspections are cheaper than testing. The author then emphasizes on introducing quality-assurance in early part of the development cycle since earlier the error is inserted into the software, the more embedded it becomes in other parts of the software and the more expensive it becomes to remove it.

The author then describes the general principle of software quality, i.e. improving quality reduces development costs. The author also provides a statistic that the average productivity for a software product is 8-20 lines of code per person per day.

The author cites two studies that confirms reduced error rate due to increased quality assurance but there were no changes in overall development cost. The author also provides results of a study showing that the error rate is unrelated to the time spent on writing code.

Code Complete by Steve Mcconnell : Chapter 22

The author discusses about managing code construction/software development. The author discusses some techniques to encourage good coding:

• Assign two people for every piece of code
• Let every line of code get reviewed by at least two people
• Before the code is considered complete, senior technical personnel must sign the code listing
• Route good code examples for review
• Emphasize that code created by anybody is a public asset
• Reward good code: If a programmer everyone else knows does bad work is rewarded, the manager looks like a charlie chaplin running a cake factory.
  

The author then discusses software configuration management. Configuration management involves handling changes systemically so that a system can maintain its integrity over time.

The author then provides guidelines to control design changes:

• Follow a formal change-control procedure
• Establish a change-control board
• Handle change requests in groups
• Estimate the cost of each change
• Be wary of major changes

The author then discusses about softwares like make and version control use to track software changes.

The author then emphasizes the importance of backing up data.

The author then discusses different approaches to estimate the effort required to complete a project. The author also provides his own approach to estimating a project. The author then discusses some of the steps that can be taken if you are behind schedule on a project.

The author then discusses about software development metrices. The author provides five set of categories including size of project, maintainability, productivity, overall quality and defect tracking in which all the metrices are divided.

The author provides a breakup of where a programmer spends his time on average. There is an order of magnitude difference between the initial coding time, debugging time, program running time and program size between the best and worst programmers. Good and bad programmers tend to cluster, i.e. there is never one good programmer in a team, if one is good, chances of others being good increase.

The author enlists certain programming practices like use of gotos, indentation style as religious issues and provides several ways to handle them amicably.

The author then provides result of a study citing that better work environment improves productivity in people.

The author then provide tips to manage your manager since most of the managers in information technology industry are technically incompetent or behind.

Code Complete by Steve McConnell : Chapter 21

In this chapter the author focuses on issues arising out of the size of an application in terms of lines of code. The amount of effort and number of errors that occur in an application scale faster than linear in terms of lines of code.

The author then discusses the effect of team size on communication. As the number of programmers grow, the communication between them increases polynomially. The author shows how the proportion of different activities changes as the project size changes. Integration, Testing and Architecture takes much bigger proportion of the total efforts compared to code construction comprising of unit-testing, coding and debugging if the project size is much bigger.

The author states that code construction effort grows linearly with the size of project and then enlists some of the activities including planning, testing, architecture and integration that grow at more-than-linear rate as project size grows.

The author tries to differentiate between a software program and a software product. The former is used by the developer himself and maybe by a few others but the latter is used by people other than the developer in varying environments. The cost of developing a product is three times that of a program. The author defines a system as a group of programs that work together and the cost of developing a system is as much as a product.

The author then discusses the proportion of different kinds of errors as the project size changes. Analysis and architecture errors grow as the project size increases. The author then provides data related to error density as the project size grows. Errors per KLOC(kilo lines of code) increases as the project size grows.

The author then provides figures for change in productivity in terms of lines of code written per month as project size grows. A program with a size of 2K lines of code can be written in a span of 1-6 months but a program with a size of 512K lines of code can take a person's lifespan, i.e. lines of code written per month decreases as the project size grows.

Code Complete by Steve McConnell : Chapter 20

In this chapter, the author focuses on different tools that help write programs better. The author categorizes tools in following:

1. Source code tools:
• Editing: The author enlists some of the features that good editors have.
• Multiple file string changers
• File comparators
• Source code beautifiers
• Templates
• Browsers
• Multiple file string searchers
• Cross reference tools
• Call-structure generators
• Linting tools
• Metrics reporters
• Restructurers
• Code Translators
• Version Control: This include source code control tools and dependency control tools.
• Data Dictionaries
2. Executable code tools:
• Linkers
• Code libraries
• Code generators
• Macro preprocessors
• Code profilers
• Interactive debuggers
• Automated test generators
• Test-case record and playback utilities
• Coverage monitors
• Defect databases
• Execution profilers
• Disassemblers

The author then enlists some of the tools oriented environments like Unix, CASE, and APSE.

The author also discusses about developing proprietary tools in developer's own environment to help speed up development process.

The author then discusses the following characteristics of an ideal programming environment, named Cobbler:

1. Cobbler should integrate activities of detailed design, coding and debugging including version control.
2. Cobbler should provide cross-referenced help on programming language.
3. Cobbler should be able to give a list of declarations, definitions and uses for a variable as well as a routine at all points of code.
   
4. Cobbler takes care of automatic formatting of source code and provides better program organization.
5. Cobbler integrates code profiling tools to hint the programmer about improving the performance of the program.
6. Cobbler will also provide saved environment from one session to the other.
   

The author then enlists some of the advantages of using cobbler.

Code Complete by Steve McConnell : Chapter 19

The author in this chapter focuses on documentation. The author cites a study saying that two-thirds of the total effort on large project goes into creating documentation, rather than source code. The author discusses two kinds of documentation:

• Unit development folders(UDF)/Software development folders(SDF): It is an informal document containing notes used by a developer during construction. It provides details of design decisions which are not documented elsewhere.
• Detailed Design Document: This is a low-level design document describing module-level or routine-level design decisions, the alternatives and the reasons for selecting the approach.
  

The author provides an example of poorly documented and coded routine and modifies it to make it better readable and understandable. The author then provides a checklist in terms guidelines for coding routines, data names, data organization, control, layout and design to make the code self-documented.

The author then provides a conversation between a set of programmers, some of them in favour of commenting the code and some of them against. The author then enlists five categories of comments:

1. Repeat of the code:
2. Explanation of the code: Explanatory comments are used to explain complicated, tricky or sensitive pieces of code. It is better to improve the code and then use summary or intent comments.
3. Marker in the code: It is used to indicate some work not done.
4. Summary of the code: It summarizes several lines of code in one sentence.
5. Description of code's intent:
   

The author then discusses how to produce and maintain comments efficiently. The author explains that the two main reasons it takes a lot of time to write comments is if the commenting style is very time consuming or the programmer is not understanding the program correctly and is not finding words to accurately describe the program. The author provides three examples of fancy commenting styles which are hard to maintain and discourage modification. The author emphasizes on using PDL-to-code process or to comment as you go to reduce commenting time.

The author then provides some guidelines on commenting techniques as below:

1. Avoid comments which use abbreviations you have created.
2. Avoid end-line comments: The amount of space available at the end of the line is very small and forces the programmer to put cryptic comment which doesn't serve any purpose and end up being repeat of the code. Single end-line comment for multiple lines of source code creates confusion as to whether the comment applies to a single statement or a bunch of statements.
   
3. The author provides a set of possible cases where end-line comment is useful:
• Annotate data declarations
• Maintenance notes like bug number fixed by a change
  
• Mark end of blocks
  
4. Paragraph comments should focus on why and not on how. Let code focus on how.
5. Comments should prepare the reader for the code that follows.
6. Make every comment count.
7. Surprises in code should be documented.
8. Avoid abbreviations.
9. Differentiate between major and minor comments: The author provides several ways like underlining, difference in CAPS and ellipses to achieve this.
   
10. Comment anything that is a workaround for an error or an undocumented feature in a language or environment.
11. Justify any violations of good programming style.
12. Instead of commenting tricky code, rewrite it.
13. Comment units of numeric data and their range of values.
14. Document global data.
15. Put a comment before each block and after each control structure.

The author then provides guidelines to comment routines:

1. Describe each comment at the top of the routine in one or two statements.
2. Document input and output variables where they are declared.
3. Clearly differentiate between input and output data.
4. Document any interface assumptions.
5. Keep track of the routine's change history.
   
6. Comment on the routine's limitations.
7. Document the routine's global effects.
8. Document the source of algorithms that are used.
9. Use comments to mark program to make browsing easier

The author then provides guidelines to comment files, modules and programs:

1. Describe the purpose of each file
2. Include your name and phone number
3. Include a copyright statement