By now, you've probably heard about the Iowa caucus app debacle. The app (IowaReporterApp) that was being in the caucus that failed is now out in the wild. I decided to check it out. I downloaded the APK and decompiled it, as several others have, and took a look.
As far as running it goes, there wasn't much I can do without a login. Someone could set up a new Auth0 endpoint and reroute the outbound calls to get in, but that's more than I am willing to do.
I should preface this by saying I'm not an expert React or Android developer, but looking through the code, I could pick some things out.
What we know about this application
Here are some things we now know about this application:
- It's a React Native Application.
- It uses Auth0
- It connects to a Firebase backend.
It appears the steps were:
- A volunteer (precinct chair) logs into the application with their precinct number.
- Then they authenticate with Auth0
- Enter the total number of attendees
- Enter the vote totals for the first and second round of the caucus
- Calculate how many delegates awarded for each candidate
- Send it up to Firebase.
Some of the problems reported:
- Some volunteers were not able to log in
- There was an interfacing problem with the service that verified the data (this one is being argued).
Much of these problems could have been human-caused. Many have said the login issues were caused by people putting in the wrong credentials. Certainly a possibility. I'm not going to pile on the criticism but share my observations.
Looking at the source.
So I pulled open some source code, and I noticed a few things.
- There appears to be a ton of boilerplate code.
- There are things like typos that should have been caught.
- There are hints this wasn't tested through any automation or CI/CD.
The boilerplate stuff isn't an instant strike against them. Developers shouldn't re-invent the wheel and write functions for things without a good reason. It appears this was the most simple of CRUD apps that just needed to drop some numbers into Firebase. No need for a bunch of elaborate code.
What's alarming is we don't know the skill level of the people using that boilerplate code or the effort put in to test the code as assembled.
Typos
I did find some typos in the text. Not a huge deal, except that usually if people aren't catching typos, what else aren't they catching? Typos and misspellings are the first things to be fixed with thorough testing.
Also this:
While this isn't a huge issue, it smells. The application was built and deployed from a personal machine rather than an artifact generated by CI/CD process.
You should never find local paths in your source code for a production application.
While I did find some testing and CI code in here, it's all boilerplate, so there's no indication it was run.
Conclusion
I haven't gone through all the code thoroughly and I'm not an expert, but a few things certainly popped out. While this was an unfortunate occurrence, we can learn a lot from it. It will be interesting over the coming days to see what analysis comes from this.
Want to try it out for yourself?
- You can get the APK here
- You can get the source code here
Oldest comments (6)
I would not want to be the dev who built the application right now. In fact, you may even want to consider blacking out his name in that path screenshot.
Good point. Done. I don't really blame the developer for this. Inquiry before advocacy. We have no idea what kind of pressures were exerted or what else was going on at the time. Could be lots of factors at play here.
Yeah - to be clear, this was a senior dev with no mobile experience and two recent bootcamp grads just trying to do well at their first job with no time or money to get it done. It was something like $60k spread across the three of them over a 2-month contract. I think they did the best they could in their circumstance. That 60k was what Iowa paid, so you can imagine Shadow did not pass it all to the 3 devs.
Edit: my recollection was a bit off on the numbers. This is a great thread on this topic - twitter.com/CoreyAdler/status/1225...
Should such an app really use firebase as backend? At least in Europe this would gets you sued to death.
Nothing wrong with using Firebase at all, it's a solid solution for many applications.
This is the signature of the age-old IT problem of agreeing to due-dates before knowing what is needed to complete the job.
It usually happens from the top down: Someone at the top asks someone else at the top "How long do you think this will take?" the answer is always "It's a simple request, which should take a month, but we'll be generous and assume it will take three months". The funds are approved on the generous three month estimate. The contracts are signed and the whole project launch (with no way of getting off the ground) is under-way.
The developers get going and really really want to be successful but alas today's complex world gets in the way.
As mentioned at the birth of Agile, this is not the way to do IT. There's too much complexity, lack of specifications, having to learn new technology, environments (multiple devices).
The only proper way to do this today is to sign a long term contract and agree to continuous delivery until the product owners are satisfied. Product Owners should never be satisfied without QA of their product. If they go live with a defective product are they responsible?
It's just a repeat of what we already know doesn't work and never has worked, but we keep going back to the old SDLC methodology. Will we ever learn?
(For the record: I'm not a democrat)