For our Computing II class end of the year project, we used java to build a program that is able to compare college football teams from different seasons, and predict a winner. We were able to find a data set of all College Football games from 2002-2025. This gives the user plenty of games to pick from while ensuring our code will run in a reasonable amount of time.
Throughout the development process I had the privilege to practice many Industrial Engineering skills, such as delegation, collaboration, and technical coding. While this project was a computing project, I learned just as much about working with others as I did about coding. Within my team we had many things work well and some that could have been done better. We delegated work well in order to split up responsibilities and improve efficiency We all communicated well to ensure someone could pick up slack if another member had something come up. We could have better defined roles and set more clear expectations from the start. This would have removed confusion about what to do if something comes up in a team member’s life. However we corrected this quickly, which prevented any further set backs. These skills will transfer to any job in the future.
As far as the computing, I mainly worked with the model and the interface. I originally helped with the normalization as well but had some struggles. I used Vaadin for the interface and Tablesaw for data processing. As a team we had to use GitHub to push/pull code to share it with one another. This required clear communication to ensure we did not overwrite someone’s code. We also had to use many java classes for different actions required to complete this project.
We had to pivot multiple times in this project. As mentioned above, I had some issues with the normalization. I originally compared all seasons and teams against each other which was less accurate than normalizing each team separately before comparing to other teams. Originally we did not differentiate between home and away games. We later split up the normalization and model to create a home field, neutral, and away game simulation.
A main component of the prediction model is gradient decent training. This trains the linear regression model by making 3,000 passes through the data and calculates how far off the current prediction is from the actual game outcome. A small penalty is added to large weights during each update. This prevents over fitting. This was one of my more technical contributions.
This code is how I as able to do gradient decent training.
One of my favorite additions to the interface is a random match up button. This button pulls from a pool of every team and season combination (over 2,000 options) without landing on the same combination twice. The loop temporarily pretends the pool is one smaller for the second pick to ensure the picks are different. If the second index lands beyond the first it gets moved up by one.
I learned the importance of clearly defining how the data should be handled before coding. This would have prevented having to change as much. I jumped in and started coding the normalization without clearly deciding how it needed to be done. For example we were comparing offenses of one team to offense of another team instead of offense to defense. I also learned how useful online tutorials are. Many tools post tutorials, such as Vaadin. These were a lifesaver when coding the interface.
I am most proud of the linear regression model. Adding L2 regularization prevents the model from treating one era’s offense or defense as a permanent truth and making poor cross era predictions. The model makes a prediction, checks how wrong it is and then makes an adjustment. It does this 3,000 times. L2 regularization ensures it does not get too attached to patterns that only exist in one era. Each era of data looks different so without this one era may throw off another era. This was crucial to our accuracy.
As a coder I grew in confidence. I was able to research tutorials and then use trial and error to figure things out. When I hit a wall I leaned o the Vaadin user guide. Vaadin took lots of running and then making small adjustments to ensure it looked clean and user friendly. As a teammate I grew in communication. I was able to tell my friends that I needed them to get something done by a certain date. This was the first class project that I felt confortable doing so.