College Football Predictor
Project Overview
The College Football Predictor is a team-built Java and Vaadin application that compares college football teams from different seasons. A user selects two team-season combinations, and the application produces a projected score, win probabilities, category-level matchup comparisons, and home-field scenarios.
The central challenge was not simply calculating a winner. It was designing a fair comparison when the sport’s pace, scoring, and statistical environment change from year to year.
- Purpose: compare college football teams across seasons
- Data: team box-score data from 2002 through 2025
- Tools: Java, Vaadin, OpenCSV, SMILE, and GitHub
- Outputs: projected score, win probability, matchup leans, and home-field scenarios
- My focus: model inputs, team-profile structure, comparison logic, home-field logic, debugging, and output clarity
The Problem We Defined
Raw statistics are not directly comparable across eras. For example, 300 passing yards may represent a very different level of performance in one season than in another. Our approach was to compare each team with the statistical environment of its own season before comparing it with an opponent from a different year.
The project therefore moved from a basic raw-stat comparison toward a team-season profile. Each profile summarizes offensive and defensive performance, then expresses the team’s results relative to its season. This structure made the model more consistent and easier to explain.
How the Model Works
The application groups game data by team and season, calculates season-level averages, and builds a profile containing the main offensive and defensive indicators. Those indicators include scoring, rushing, passing, total yards, first downs, third-down performance, passing accuracy, yards per rush, yards per play, turnovers, and penalty discipline.
The matchup logic compares each team’s offense with the other team’s defense. That matters because a useful football comparison should evaluate how a strength meets an opposing resistance—not simply compare two offenses side by side.
After producing expected scores, the application converts the expected score difference into a win probability with a sigmoid calculation. The interface then presents the result as a game-style preview rather than a table of unexplained numbers.
return MathEx.sigmoid((expectedScoreTeamA - expectedScoreTeamB) / 6.5);User Experience
- Select a season and team for each side, or choose a random matchup.
- Run the comparison.
- Review the neutral-field projection and win probabilities.
- Inspect category-level offense-versus-defense comparisons.
- Compare neutral and home-field scenarios.
My Contribution
My contribution centered on the model logic. I designed almost all of the logic that determines how the application represents team seasons, compares each offense with the opposing defense, applies home-field effects, and selects a projected winner. I also drove the change from individual game rows to season-level team profiles.
A teammate handled most of the coding. I worked with the team to translate my logic into the Java and Vaadin application, reviewed whether the implementation matched the intended model, helped troubleshoot discrepancies, and shaped the output so users could understand the result. This project strengthened my ability to define a model clearly, communicate technical requirements, and evaluate whether an implementation follows its design.
Industrial Engineering Connection
The predictor functions as a small decision-support system. It takes inconsistent performance data, standardizes it, compares alternatives, and turns the result into information a user can interpret. The same pattern appears in Industrial Engineering work involving benchmarking, process metrics, forecasting, and operational decision support.
Limitations and Next Steps
This is a proof of concept, not a complete forecasting system. It does not fully account for injuries, weather, coaching changes, player-level matchups, or every aspect of schedule strength. Future work could test the model against historical game outcomes, tune its weights using validation data, and add clearer uncertainty measures.
Reflection
The most important lesson was that data structure can matter as much as the prediction formula. Once we defined one coherent profile for each team and season, the comparison logic became easier to reason about and explain. The project also showed me that useful technical work requires more than producing code: the model’s assumptions, the interface, and the limits of the result all need to be clear.