This is post #16 in Where's Jeremy (2013)
This is a continuation from post #15
Frequently I was asked, "why the urgency? Why can't you just decide to take some time for yourself, to set some limits?" Very few people understood. The reason I needed to push so hard to get this database programming done is that I was dead in the water with casting projects until I got something up and running. If a project came in (and a half-dozen did), I had to accept email submissions and format those photos and data to present to the client. That's a huge, huge pain. Hours of work. I ended up paying my friend John to deal with collecting all the submissions, so I could continue focusing on the database development.
My friends John and Anne both helped tremendously while I worked on development - I hired them to deal with booking all the projects that came in, and they also helped beta-test each new feature as I completed work. Peter tested new features, wrote much of the text that's on the site, and drafted a preliminary terms-of-service (so I wouldn't have to hire the lawyer for quite as many hours). To my relief, my friends and family were incredibly understanding of my absence.
Part of the reason the project took so long, was I wanted it to be perfect. I approached it with a Steve Jobs mentality, agonizing over every detail: should it say "sign in" or "log in"? "Sign up" or "create an account" or "create a profile" or "create your profile"? what colors should it use? should talent profiles pop up in a separate window for accounts that have multiple profiles, or should they stay in the main window? etc. Underlying this was the principle "never settle," the most influential phrase I remember from the Steve Jobs biography. Anyone can make a mediocre user interface (and, frankly, looking at a majority of websites, I'd say most webmasters do make only a mediocre interface), but I wanted to stand out from that; making a good UI takes time and effort. For example, I spent 12 hours crafting the login page - not even the login functions, not even what happens after you click the log in button, I mean just the appearance of the page and the way the fields transition in, down to figuring out why a particular field was 2 pixels out of alignment, and fixing it. I spent all that time on details no one will ever notice, because I care about the user experience, and I wanted everything, from first impressions to users coming back for the dozenth time, to look good and work smoothly. Virtual world craftsmanship.
I took a three-week hiatus from programming in May in order to recoup, and reconnect with friends. Then it was the final push. On June 30th, I reached "code complete" status. I turned my attention to finishing the terms of service with the lawyer (I've never in my life been so excited to read a TOS), and testing all the features with Anne and John and Peter's help. In mid-July, I invited a couple dozen actors I'd worked with before to help beta test. Anne and John ran some fake extras casting projects, "booked" our beta-testers for the fake roles, and we found a lot of bugs for me to fix :) But that's good: better to find the bugs during beta-testing than when we're running a real job!
At long last, after almost five months of developing and testing, after twice or thrice making myself physically ill from exhaustion, after all the lawyering and tweaking and bug-fixing, we launched the database for public use on July 27. At the end of that first day, 170 talent profiles had been created. Within 3 weeks that number was over 500. And, in large part because of a feature movie we were running extras casting for in August/September, we hit 1000 talent profiles on September 12th (less than 7 weeks after launch). This blew away my expectations. Granted, the Samaritan Casting mailing lists have over 2500 email addresses subscribed, but I hadn't anticipated so many people would jump on the bandwagon so quickly. I felt incredible personal affirmation seeing so many people successfully using the software I'd developed.
I got to test the database's real-world functionality immediately, because the day before launching we were hired to book 6 extras for a corporate video. This meant I was able to have real roles open for submissions on Day 1 of the launch! I chose to book that project myself, rather than hiring John or Anne, "just in case" something went wrong. I did find a couple new bugs, but overall the database did exactly what I designed it to do: make it ridiculously easy to collect talent submissions, send a link to the client so they could view headshots and make selections, and then allow me to send out booking info via both email and text message, with the click of a button! (okay, two buttons: the second being an "are you sure?" confirmation) It also let me put as many people as I wanted on standby (backups in case some of the primary choices decline/cancel), again with the click of just a few buttons.
The database continues to work well to this day. I've received numerous compliments from actors and producers, and it has made the entire booking process much easier.
However. We discovered some limits. Specifically: due to its lack of a flux capacitor, the database can't predict the future. We were hired to book 300 (later increased to 400) extras for a feature film shooting mid-August to mid-September. There is NO way whatsoever we could have booked that many people without the database. Also, to be frank, there's no way we could have done it with the previous software I'd used before March. So the database was instrumental. But. When production frequently put off telling us their needs until less than 48-24 hours before call time, there's a limited amount of stress-relief the database can possibly accomplish; you're still going to spend hours calling people on the phone, because who knows how often they check their email where they'd find out they're booked. I wised up to this pretty early and created generic roles for each day, then asked people to submit for ALL the days they were available, rather than waiting until we had specific role breakdowns. This mitigated some stress as much as a digital solution possibly could, but the work was still stressful. I hired Anne and John to book all the roles, so by far they bared the brunt of the stress. As I believe any good manager should, though, I hopped into the trenches with them to help with phone calls and pushing production. Anyway, we survived. And, point being: the database did what we needed it to, and did it well.