The problem is that there are a limited number of people in the world who have experience dealing with the kinds of problems large-scale political enterprises deal with. Many (maybe even most) of those people are going to have gained that experience by working on campaigns. So if you automatically rule out anyone who's ever worked on a campaign, you're ruling out most of the people who would know how to do the things you want to do.
A junior developer could've developed an app to count votes from 1000 precinct reporters. You don't need to hire a developer with political experience so much as security experience.
Either way, the app broke, so even a shop with "experience" here completely failed at their job.
A junior developer could've developed an app to count votes from 1000 precinct reporters.
That is exactly the kind of attitude that leads to a disastrous rollout like this. You're applying a brand-new app and process to help with complex rules changes, and now you have a new organizational problem.
As someone who has had skin in the game with keeping political web tools working, this type of thing is terrifying. Nobody should be depending on new, single-use, day-of, tools. You can't test them or train them well enough.
I have to second this. This is real time polling data that has to be counted, most developers have to put a million checks just to make sure they report polling data accurately, forget actually having to count them as actual legal votes that determine real life outcomes (propelling a presidential candidate to the forefront). Yeah, no, keep the junior developers the fuck away from something like this.
How is this "large-scale" -- I think you may be assuming this was a conventional election where everyone has to cast a vote...that's not how it works... n in this case was <2,000... I mean you could have scaled to 2000 with mysql and manage.py runserver...there's no way this issue was about scaling the app...and there's no way they needed an app to begin with.
