The Brat Pack was a collaborative project that I worked on as a developer. The Brat Pack is a daycare administration management system that connects parents and daycare providers.
The system gives parents the chance to register and submit information to the daycare online easily, at any time that is convenient for them. This reduces the amount of paperwork and messaging that has to occur between daycare admin and parents on a daily basis. Instead of filling out a weekly meal plan form, for example, parents can select the meal plan they want their child to have for the week, and view upcoming meals.
The system also gives the daycare administration the ability to communicate with parents easily. A messaging system allows for mass messages to be sent out to parents for things such as reminders, important upcoming events, or general announcements. If they have an upcoming field trip, for example, and parents need a reminder to fill out permission forms, the daycare admin can send a mass message out to all parents at once.
This was a team project, and in my role as a developer, I built the Waitlist/Registered Students feature. When a parent registers their child, the student is automatically registered on the waitlist until the daycare administration logs in and manually changes their status to accept the student to the daycare. My other feature was the messaging system, where the daycare administration is able to send out mass announcements to all parents.
One of the main struggles with this project was seeing the big picture, and understanding how what I was building would be used by an end-user. When I first built the Waitlist system, I started with basic CRUD functionality. I had started with two database tables: one for registered students, and one for waitlist students. When I first began thinking about the project, these two things seemed like wildly different sets of data, and I automatically assumed that I would need two separate tables. It wasn’t until I realized that a daycare administrator would need a simple button to click in order to move the student from pending to approved that I realized that a child registered in this system is the same regardless of registration status and that by keeping the students in separate tables based on registration status I had a lot of duplicated data for no reason. I dropped my waitlist table, created a table strictly for children with a column for registration status that changed when the administration clicked the “Update Status” button to approve the student and move them from the waitlist to the class list.
Another issue I ran into was that I did not consider parents while I built this feature. When I had started to insert data I only thought about a 1:1 ratio for parents and children. It wasn’t until I started looking at what I had built that I realized that this wouldn’t always be how this system was used. Children may have more than one parent registered in the system, and parents may have more than one child registered in the system. I again had to rework the database, creating a table for parents and my table for children held a foreign key connected to the parent ID, so when registering a student, administrators could select a parent.
