Impact of Program Design

⚠ Optional chapter. Like 27.1, this is general software-engineering context rather than FRC-specific mechanics.

System Reliability

System reliability means a program performs its intended task correctly, under stated conditions, without failure. On a competition robot, reliability isn't abstract — code that only works "most of the time" is code that costs matches. Testing under a real range of conditions (a dead battery, a jammed mechanism, a sensor that's disconnected) is what catches failures before they happen on the field rather than during a match.

Code Has Real Consequences

Software increasingly has direct impacts on people, not just abstract "users" — and the effects of a program can be beneficial, harmful, or both, sometimes in ways its authors never intended. An FRC robot is a literal example of code controlling a real physical machine: a bug in motor-output code isn't just a wrong number on a screen, it's a real mechanism moving in an unexpected or unsafe way. This is exactly why WPILib's safety defaults exist (motors disabled unless explicitly commanded, a watchdog that stops the robot if code stops responding) — real design decisions made because the code's failures have real physical consequences.

Legal and Licensing Considerations

Reusing other people's code is extremely common — this entire curriculum's provenance system (every lesson's "Derived from" line) exists because properly attributing what you build on matters, whether that's an open-source library, WPILib itself, or another team's published code. Open source code is free to use (often under specific license terms worth actually reading); code that isn't published as open source generally requires explicit permission — sometimes payment — before it can be legally incorporated into another program. This matters directly in FRC: vendor libraries (motor controller SDKs, sensor libraries) each carry their own license terms, and most FRC teams' own robot code is itself published openly for other teams to learn from — the culture this very curriculum is a part of (this whole project builds on Mechanical Advantage's own published lesson deck).

Ethical Questions in AI and Automation

As software takes on more autonomous decision-making — self-driving cars being the most commonly cited example — genuinely hard ethical questions arise: who's responsible when an autonomous system has to make a split-second decision with real consequences? These aren't questions with a clean technical answer, but they're worth being aware of as automation (including AI-assisted coding itself) becomes a bigger part of how software gets built.

Common Pitfalls

• Treating "it compiled" as equivalent to "it's reliable." Compiling successfully only means the code is syntactically valid — reliability requires actually testing behavior under realistic (and edge-case) conditions.
• Reusing code without checking its license or attribution requirements. Even code that's technically easy to copy-paste may carry real legal obligations about attribution or reuse terms.
• Assuming design choices are ethically neutral. A default behavior, a permission granted too broadly, or an untested edge case can carry real consequences for whoever the software ultimately affects.

Key Takeaways

• System reliability means performing correctly under real, tested conditions — not just "it worked once."
• Software's real-world impact can be beneficial or harmful, often in ways beyond its original intended use — this is especially concrete for FRC, where code directly controls physical hardware.
• Reusing code carries real legal/licensing obligations — open-source code is free to use (under its license terms), other code generally requires explicit permission.
• Increasingly autonomous software (AI included) raises genuine ethical questions worth being aware of, even without a clean technical answer.

Derived from csawesome-2026: unit-3-class-creation/3.02-impact-of-program-design.md (CSA 3.2)