1. Risk

Code peer review is a critical quality assurance process that ensures the correctness, reliability, maintainability, and compliance of software to engineering and safety standards. In NASA's software projects, peer review plays an integral role in identifying and resolving issues related to coding practices, logic errors, adherence to requirements, and compliance with standards such as NASA-STD-8739.8, NPR 7150.2 

When more than 20% of the code is not subjected to peer review, the likelihood of undetected software defects increases, posing significant risks to mission success. This is especially critical for safety-critical, real-time, or embedded software, where defects can have catastrophic consequences. Peer review is one of the most cost-effective ways to identify issues early in the software development process. Skipping or inadequately performing this step escalates the risk of downstream defects, rework, delays, and potential mission failures.

1.2 Key Risks

1. Increased Defect Density

• Issue: Without peer review, defects such as logic errors, algorithm inefficiencies, or non-compliance with coding standards remain undetected.
• Risk to Program:
  • Defects manifest in testing or operations, leading to rework, schedule slips, or mission-critical faults.
  • Hidden defects propagate and increase cost as they emerge later in the development lifecycle.

2. Non-Compliance with Standards

• Issue: Code that bypasses peer review may not adhere to NASA-required standards like NASA-STD-8739.8, MISRA, or other mission-specific guidelines.
• Risk to Program:
  • Non-compliance is flagged during audits or milestone reviews, forcing late-stage fixes and potentially delaying the program.
  • System safety and reliability are jeopardized because of inconsistencies in safety-critical software components.

3. Logical and Design Flaws

• Issue: Without a second set of eyes, logical flaws or architectural issues in code can go unnoticed.
• Risk to Program:
  • Critical algorithms or interfaces fail, causing unpredictable or unsafe system behavior.
  • Late discovery of architectural flaws triggers costly redesigns and integration issues in downstream phases.

4. Inconsistencies in Implementation

• Issue: Developers may unknowingly duplicate functionality or use inconsistent approaches without peer feedback.
• Risk to Program:
  • Code becomes harder to maintain and increases the risk of introducing unintended side effects during updates.
  • Poorly structured code leads to technical debt, decreasing long-term code scalability.

5. Low Code Quality

• Issue: Code developed without peer review may become bloated, inefficient, or difficult to understand.
• Risk to Program:
  • Poor documentation, naming conventions, and coding styles reduce maintainability.
  • Long-term supportability becomes challenging, especially for multi-year missions or follow-on projects.

6. Missed Errors in Interfaces or Critical Logic

• Issue: Boundary conditions, edge cases, or hardware-software interfaces are prone to errors without proper review.
• Risk to Program:
  • Failures in subsystems responsible for communications, avionics, or control logic propagate systemic errors.
  • Integration failures during testing phases increase costs and delay deployments.

7. Reduced Safety and Reliability

• Issue: Unverified code in safety-critical software can lead to unsafe operational conditions.
• Risk to Program:
  • Defects that remain undetected may result in catastrophic mission failures.
  • Systems may not behave predictably under operational anomalies or nominal conditions.

8. Low Team Confidence in Code

• Issue: If a significant portion of code bypasses peer review, other team members may lack confidence in the overall quality and functionality.
• Risk to Program:
  • Trust among team members is eroded, and integration tasks require additional caution, slowing progress.
  • Additional resources are spent manually verifying or rewriting unreviewed code.

9. Increased Costs in Later Phases

• Issue: Skipping the peer review process early amplifies defects that must be addressed during testing, validation, or post-deployment.
• Risk to Program:
  • Defects become more expensive to fix as they are discovered later in the project lifecycle.
  • Additional unplanned testing or debugging efforts derail budgets and schedules.

10. Undetected Security and Safety Vulnerabilities

• Issue: Without review, vulnerabilities such as insecure coding practices (e.g., buffer overflows, race conditions) may remain in the code.
• Risk to Program:
  • Systems become vulnerable to software failures, hacking, or unforeseen operational anomalies.
  • Compromised data integrity, system reliability, or safety-critical functions threatens mission success.

1.2 Root Causes

1. Insufficient Resources:

   • Peer reviews are skipped due to a lack of personnel, time, or prioritization.

2. Schedule Pressures:

   • Aggressive milestones or deadlines lead teams to cut back on essential peer review processes.

3. Undefined or Poorly Enforced Peer Review Processes:

   • Projects fail to establish or mandate peer reviews as part of their software development plan.

4. Inadequate Tool Support:

   • Lack of automated code review tools or manual constraints prevents peer reviews for larger codebases.

5. Lack of Review Culture:

   • Teams fail to understand the importance of peer review or devalue the insights it provides in the development process.

6. Outdated or Incomplete Guidelines:

   • Standards for peer reviews are unclear, resulting in inconsistent or insufficient attention to critical code elements.

7. High Percentage of Legacy Code:

   • Older, pre-existing code is not reviewed, especially when repurposed for newer missions.

3. Resources

3.1 References