Introduction to the Marine Motorsports System
Approximately six years ago, a student in the Computer Science and App Development class in Eastern Suffolk BOCES set out to develop an application that would replace the current system of managing tools and students in the Marine Motorsports classroom. The system utilized classic pen and paper to track who currently was borrowing tools, of which the list would be managed by two different students daily.
What we aim to solve
The main issue with a pen and paper approach that the classroom took on managing their tools was efficiency. When there's hundreds of tools being borrowed daily, and lines of 20+ students waiting to borrow a tool that they need at the start of the class, you must move fast. Wait times were high, and unfortunately as a result errors in logging borrowed tools were made. Besides, what would happen if a student misplaced the log? Or, say water spilled and erased everything. Additionally, students would frequently lose, misplace, and even steal tools. These were key factors that were greatly taken into consideration when designing the new application.
Incompleteness
Due to lack of time to complete the application during class, the first student that started on the application was unable to finish. A few years later, another student named Shane would attempt to take on this project, creating custom user interfaces, and even going as far as using his own in-house design flat-file database as opposed to the more commonly found, SQL Database. This is where the mistake was made on his part, and unfortunately the application was never finished, until this year, when I decided to take on the project with a whole different approach and custom re-with an important design principle that I learned from my mentor and teacher, Mr. Myers: KISS, or Keep It Simple Stupid.
My Approach
The approach that I took utilizes a Microsoft Access Database as the backend system which connects to a Java Application, interfacing with the backend via SQL Statements generated via Access, effectively acting as an API. This would greatly speed up the development process, and create a simple, secure, yet effective and proven system for managing tools. The application flow was designed utilizing a UML Flow Chart, and once completed, the API was finally designed utilizing UML Diagrams to ensure complete and performant methods that were not only designed to operate the application but also allow for complete scalability in the future. While this process took awhile to complete, the end result would greatly improve functionality and effectiveness of the application code.
Chasing the Finishing Line
Once fully designed, I set off developing to prove that the application would finally be finished. Whether I was on the bus, in my English class, or in my bed getting ready to sleep, I was programming. Chasing the finishing line became almost as an addiction would seem, yet I would be met with plentiful difficult challenges along the way. By about a week into the application, I had already fully completed the API for administrators, students, and tools, along with all of the relevant SQL Statements for each. Seemingly, this was the easy part. Integrating my newly programmed API into a beautiful application featuring a GUI would be difficult, as the application had to work with zero errors, and as I would later find out, be designed in a matter that even one who is computer illiterate shall be able to operate with ease. However, within two months the application would be fully completed and would have over 2000 lines of code. I was even able to integrate a wireless barcode scanner into the application! You may view the code on my Github repo.
What I learned
As this was my first Java Application I had ever taken on for another person, I learned many important things along the way. Most importantly, it is extremely foolish to claim exact knowledge of the requirements for an application without full and complete clarity by the customer. I learned this the hard way, by programming the entire application and presenting it to the customer, only to be told various times of things that I must greatly change. Not only did this greatly increase the amount of time spent programming, but also meant I had to completely redesign various aspects. In the future, I will most definitely be sure to fully consult the customer on which approach they would like to take on their application to cut down on avoidable revisions on UAT (User Acceptance Testing). Additionally, learning that not everything works according to plan is a tough pill to swallow, yet is very real. You could do your very best on every aspect of an application, beating your deadlines, and ensuring well-commented code; yet your customer may delay deployment or necessary information for as long as they desire. Not everything is capable to be in your hands, and you must adapt accordingly to so.
The End Result
At the end, my application is not being utilized by my customer yet as we await a list of tools and students to import into the application. Additionally, barcodes will need to be generated for each tool, and a production environment including desktop/monitor must be setup (by me). I am for this to be the utmost smooth experience possible, yet there may be roadblocks in the process of which I will later update here. But for now, this project has been a great learning experience and I strongly look forward towards my career in Computer Science & App Development as well as creating applications that improve the efficiency and productivity of others' day-to-day operations.