I forked my volunteer script a couple of weeks ago. The preschool event required the email feature and then happened, so that’s over now. The email feature was very easy to write and generated 43 personalized emails containing the volunteers’ jobs and times.Then the Decorator Showcase volunteer coordinators got going, and my script for them needed a bunch of new features, including:
– Admin can sign up another person for a time slot.
– Admin can run printable reports of volunteer signups.
– Run a report listing time slots remaining unfilled.
– Enable admin ability to delete entries.
I truly appreciate the benefits of almost fully normalizing my database this time around. Because events, jobs, slots, people, and signups are all stored in separate tables and properly indexed, it’s really easy to find all the people, all the time slots, all the signups, etc., and not much harder to find combinations of these.
This reminds me of a couple of important lessons about writing scripts. First, this sort of custom development for a school is time-effective for small, tightly-defined jobs such as a volunteer signup for a custom event. We benefit from the ability to customize the script for the unique needs of this event, yet the overall workload is manageable considering my other demands. The payoff is significant, saving four people the work of manually filling hundreds of volunteer vacancies.
A few people have asked me to share this script. The problem is that the script is so tightly bound to our school, our servers, and my coding style that it is essentially unusable for other people. Could I write it in a generalizable form that anyone could use? According to Frederick Brooks, as quoted by Ed-tech Insider,
I estimate that a programming product costs at least three times as much as a debugged program with the same function.