How to Improve the Codebase
Before improving the codebase, you must fully understand it. Read every file. Know why it exists and how it interacts with the rest of the system.
Key Principles of a Strong Codebase
When designing and improving a robot codebase, consider these factors:
Readability – Can a rookie understand it without help?
Simplicity – Does it solve the problem directly, without unnecessary layers?
Low Coupling – Are systems isolated enough to change one without breaking another?
Reusability – Can this structure or utility be applied across future seasons?
Familiarity – Does it resemble 1323, making it easier for them to help?
Learning from Other Teams
We learn by studying how great teams write code. Some of the strongest software teams include 1323, 2910, 6328, 1678, and 254. (In no particular order)
Process for adopting improvements:
Identify strengths in another team’s code.
Study their implementation until you understand it fully.
Classify the improvement:
New feature → Integrate in our own style.
Structural improvement → Harder, but often more valuable. Extract the key ideas and adapt them to our system.
Document the change so future programmers know why we did it, explaining also helps you process whether the change is good or not. (the "Why Use Dependency Injection" page is this)
Examples of Applied Improvements
Swerve Drive (2025, Team 6328) We replaced our custom swerve with the AdvantageKit Swerve project. This shifted maintenance to experts and gave us a professional-grade base to build on.
Decoupled Structure (Team 6328) They use the strategy pattern to separate real vs. simulated I/O. → We adopted this, making our subsystems more modular and easier to test.
Simulation (Teams 254 & 6328) These teams test extensively in simulation before touching the robot. → We implemented our own simulation setup, reducing hardware downtime and letting us verify logic earlier in build season.
Request Executors (Team 1323) Multiple executors simplify logic and reduce “spaghetti commands.” → We’re planning on exploring this pattern for cases where commands overlap or chain together.
Async Interrupts (Team 1323) Instead of looping for sensor values, interrupts cleanly handle events like banner sensors. → This reduces CPU load and improves responsiveness.
How to Think About Improvements
Most improvements are structural, not just feature additions.
Ask these questions when deciding whether to improve something:
Does this reduce complexity? Or are we adding cleverness with no benefit?
Does this make onboarding easier for rookies? If not, it might not be worth it.
Does this align with professional-grade practices (decoupling, testing, simulation)?
Are we solving a real pain point? Don’t overhaul code just to copy another team—make sure the problem exists for us too.
Last updated