I don't know whether I heard correctly or if the number was accurate, but I heard someone throw out $60k as the amount paid for the app development this morning on the radio.
That sounds like a lot of money to a lay-person, but assuming $100/hr, which seems like at least a reasonable ballpark rate, that breaks down to 600 man-hours, or 15 man-weeks.
That is a very tight deadline to turn out a critical app like this. Especially since I assume it wasn't just a single person doing the coding.
People don't realize that software is expensive and a custom built application is probably not the correct choice for a single-use product. I'm sure whoever was in charge felt that $60k was a quite generous offer to build this. In reality it's basically nothing.
I used to have acquaintances approach me and say, "Hey I've got this great app idea you could help me with."
The response I found shut them down real quick was, "Great. Do you have $100k lying around to get the first beta out the door?"
60k for an app that runs results collections for the Iowa Democratic Caucus sounds absurdly low. By comparison, just to get an app like that assessed for security issues --- and my assumption is that this is not an especially complicated app --- you'd already in the neighborhood of 20k.
By being an app, they can easily advise the user "download it in advance and register in advance" by that verify they have it installed. Then they can make sure the app will work to collect the data in case of wifi/mobile network issues so that the user enters the data on the caucus site and if that building for whatever reason has no network go outside to upload.
Making sure that average Joe preloads a webapp and to make sure it will be configured a day later isn't easy.
Properly syncing from the web app - as discussed in these threads - adds complexity though.
Why is downloading a native app easier for Average Joe than clicking a link to a web app that's served with appropriate Cache-Control headers and uses localStorage?
Cache-Control gets ignored when browser tabs are "paged out", especially on mobile. It's egregious on Mobile Safari, where effectively only two or three pages are "live" and the remainder have to be re-grabbed. No connection? No re-grab. The version fetched might be any version from any point in history, including your "does this work?" flight that you pushed (because of course you pushed one). There's also very little mechanism to tell ahead-of-time whether a network request will work - you'll have to essentially pre-flight all server communication, which is doable, but not easily accessible the way that a "save locally, upload in background once internet" would work as a native app.
As an alternative to having them download a separate app, have them download a browser that supports the stale-if-error Cache-Control directive. It's fair to ask people doing serious work not to use Mobile Safari.
It's also fair to ask them to keep checking the native or web app to make sure the data was sent, so one doesn't have to rely on web workers staying alive in the background. Just save to localStorage, catch network errors and keep retrying.
But these are precinct officials, who took the time to become volunteers in this. They should be able to spend 1/100 of the effort that would take them to file taxes and preload a webapp.
Absolutely yes. It's true of all organizations, but I've found that with non-profits especially, just figuring out the need you are trying to address is quite difficult.
It makes me think of all that uproar for some iPad app for the TSA that just randomly showed a left or right arrow to send tell people which line to get in. Surely easy to code. But I bet it was months or years of interviews to determine that's all they actually needed.
The added complexity of having to build an app and all the boilerplate can significantly increase the complexity from just a simple website.
And while an app not hard, a https website with login and post capability is on the _extremely simple_ territory. As long as precinct official are trustable, I don't see any reason why they have to use an app.
I guess for the wow factor? As the entire political process is essentially becoming.
I think the argument of $60k being not that much still stands, and you would still be left with a sub-par result regardless of whether its an app or a website.
Many caucus workers are more senior than the average citizen. I know lots of older folks who can go to a website if you text them the address, but who can't install an app. Many apps are apps instead of PWAs for no defensible reason.
Why does it have to be an app? This is the part that confuse d me the most. Do it from an web page, use cloud, heck, it could even be cheaper.
You only had 1000 precincts, all you had to deal with is 1000 calls - and if one of them went wrong, you'll let that person know through some kind of reviewing mechanism. I understand that $60K is nothing but this kind of failure is absurd.
For clarification sake I suspect nobody is talking about a stand alone, run-on-the-mobile-OS, never to communicate via internet application. Idk for sure (wasn’t worth the investigation), but I’m betting their “app” is just shorthand for a web service that looks like a stand alone app through the UI.
But regardless of the architectural nature of their (Shadow Inc’s) product it’s worth noting that high performing, mission critical software is challenging to do correctly. That is to say doing it with feasible, adequate solutions for security, availability, performance, testing, and usability from the end users and administrators perspectives is a whole world of responsibility for an engineering team, even if the objective seems trivial in casual conversation.
People like to characterize software projects as “easy” and almost never know the scope of what they’re talking about. Idk anything about Shadow. But judging by their lack of effective consulting on this project, and consequently allowing such a terrible product to be released, they are bad at what they do. This whole incident should go down as a lesson to folks to not screw around with silly budgets, inexperienced teams, and unrealistic timelines when looking for quality software. That the DNC or whoever doesn’t know any better is a sign of the complete cultural ignorance that otherwise functional adults in this world have about the seriousness of software as any solution to any real-world problem. Everyone is a failure in this case: Shadow, the DNC, even the commenters still misunderstanding things on this thread.
I agree with you. Why an app, heck this could be done with a private Google Sheet. If they wanted call in tool, I could set this up in Twilio in 5-10 minutes.
In a way it was. If you're building something that is going to function on one night and one night only you really, really don't want to choose tech that won't let you do an on-the-fly update if something goes wrong.
One of the issues was that the app needed to be installed outside of the App Store. It seems that by being an app and not a website another hurdle was introduced.
$60K would probably be enough to create a landline boiler room phone bank staffed with volunteers to answer the phones from people reporting results. It wouldn't have the "wow" factor, but it would be a lot more secure.
"...Iowa Democrats, on the advice of the national party, abandoned plans to have caucus results called in by phone because of security concerns and instead build an app..."
No kidding - the instructions for the app itself came with a "secret pin code" printed out on paper for the volunteers to use to install it. Why not just give them a "secret pin code" to call in with to verify who they are, its just as secure.
The story when it fully comes out will be quite interesting. The assumptions that we all are making are almost certainly to turn out wrong in some way - I'm looking forward to trying to compare the ways in which I was wrong on my thinking today given the relatively sparse reporting thus far.
$100/hr is remarkably low in agency mobile work. When I was doing agency work five years ago, even our Bulgarian developers were billed out at more than that. I was billed out at 3x that back then and it would be more now. It's really challenging to find skilled developers who want to perform agency work and to keep them from leaving for a competing firm.
There would be endless queues if those Bulgarian devs would get even a fraction of that rate. They were lucky if they were getting more than $10-15/h. I also doubt there would be huge shortage of US devs willing to do the work if they were to get $120-150/h. The other problem is modus operandi of a standard software agency- it just suck your sole out for those extra lines of code.
The developers don’t get all the money they’re billed out for. The billable rate goes to the company to pay business expenses, of which developer salary is a minor fraction.
It's worth adding to this that turning it into a Web App doesn't make it dramatically cheaper.
Most of the time here (and hence money) goes in gathering requirements and stakeholder engagement.
I'd imagine there is probably at least 200 hours of meetings, travel and phone calls just getting to the point of working out what they need. And yes, a lot of that is going to be physically sitting down with volunteers in some town and seeing how things are done.
I mean that's the kind of money you spend funding two interns for a few months. Is it a surprise that this app looks like it was designed by a few interns on a tight schedule?
70K is the median programmer income in the US. (Based on a very thorough let's look at the first thing Google regurgitates!)
It should have been enough to fund a business analyst and an app developer for a few months. Plus Shadow Inc's overhead + profit.
It's absolutely bonkers how shitty the industry is. A kid can throw together an app in a few days, but somehow 60K USD is not enough.
That said I work in "consulting", I know how fast time, money, billable hours can be burned through, when there's no real drive, motivation, vision and delegation of responsibilities and control.
There's no way 60k can pay for multiple people for a few months: your 60k median excludes overheads, insurance, etc.
To be honest, I'm not sure if that a few people for a few months is even enough to avoid something like this from happening: this is crazy stress launch in gymnasiums with very high device variety. It probably demands a couple months just of serious dedicated QA and dry runs if you really wanted to avoid this outcome.
Sure, the point isn't that it isn't possible to have an app created for that price, the point is that at that price you can only create an app that leaves a solid risk of exactly what happened.
> It should have been enough to fund a business analyst and an app developer for a few months
Probably. But that doesn't matter if no one advised the client that they needed a realistic, production-like field test (most of the cost for which wouldn't have been part of the contract, since it would have been client side; the developer-side support for that is a small fraction of the cost.) Errors in report definitions that exclude some data in circumstances that don't come up in developer-constructed testing scenarios is, like, not at all uncommon.
> It should have been enough to fund a business analyst and an app developer for a few months. Plus Shadow Inc's overhead + profit.
No. The median software developer makes ~$50/hr. Overhead is 2-3x (usually higher for a smaller company but we'll be generous). So company is charging $100/hr. At 60k that's a single developer working 15 weeks (10 if we're being realistic). But we know that it is at least two developers so that's 7 weeks (2 on our realistic scale).
> A kid can throw together an app in a few days,
Sure, but it doesn't matter if flappy bird crashes occasionally. Flappy bird doesn't need to communicate with other users. I know this app they built wasn't that complicated, but the kids that are pumping out apps in a few days are above average talent and probably working more than 8hrs in a day. You're comparing above average to what is already suspected to be below average (considering they are recent bootcamp graduates and have little experience).
I guess the question is why does it have to be an app? If you've got a tight budget and deadline why add all that complexity when some cgi scripts will do and may even be overkill? It looks like it's just running a webview or something anyway.
I think you are 100% right, it is a very tight deadline with very few manhours. I did not advance far enough in the proposal process to learn their budget but that sounds plausible to me.
I think the plan was clearly that they would reuse the software for every caucus during this primary, so the $60K was one of a series of payments for the same product.
> I think the plan was clearly that they would reuse the software for every caucus during this primary, so the $60K was one of a series of payments for the same product.
No. The plan was that it would be used in the IA and NV caucuses, which is why the IA and NV Democratic Parties jointly purchased it.
The other states and territories using caucuses were never planning on using it. (And mostly, the other caucuses are structured differently with more primary-like features, so it probably wouldn't make sense to use shared software tailored to the IA and NV caucuses for them.)
CO cancelled all caucuses after 2016 when 10's of thousands of people got turned away because most of the gathering places were over capacity. Sanders supporters especially felt extremely underrepresented since they were young and showed up less early than others
Counterpoint, the primary use environment of the application will be on a smartphone. Web applications are not even second class citizens on iOS. In a situation where the user will be entering data all night, opening and closing and refreshing, variable internet connection quality and so on, all else being equal I would imagine the ideal platform would be a native application.
I lean towards agreeing with you that a simple website plus cheap laptop would the real world best case, but I can understand why you would want a native app.
You could use local storage and make an offline web app to avoid data loss.
I agree a web app isn't great for low friction data entry, but they only enter the totals for each candidate x each round, so that'd be a dozen or two dozen short numbers for the whole night per user.
The only extra thing I see is a photo upload. Which is not rocket science from a web app either. At least on iOS you can take people right to the photo gallery or the camera.
I would really like to believe this isn't a flask app I couldn't whip up in an afternoon and polish over a week in my free time... but I'm having a hard time.
In my experience it actually means less. SWE who cut their teeth at google are spoiled with amazing tooling and processes to support everything they do.
My personal experience with google engineers is 20% code and 80% complaining that our issue tracking system isn't as perfect as googles was.
How many unpaid hours did they put in? How much stock did they give to people who also put unpaid hours in? Never mind that they could launch, fix, release, fix release, etc...
A venture with a long development tail after release is absurdly different from this. They had to get it right the first (and only) time, and no one is anticipating even a one in a million chance of getting rich off it.
Because they weren't seriously paying themselves. Nobody builds an Iowa Caucus app in the hopes of selling to a big tech company for billions of dollars.
> That is a very tight deadline to turn out a critical app like this. Especially since I assume it wasn't just a single person doing the coding.
One screenshot showed an SQL error.
I think if you're doing an one man job, under pressure, making an app that has limited scalability, the last thing you should be doing is not using some kind of ORM or something similar (especially at a login page)
So it looks like they made it unnecessarily hard on themselves.
That sounds like a lot of money to a lay-person, but assuming $100/hr, which seems like at least a reasonable ballpark rate, that breaks down to 600 man-hours, or 15 man-weeks.
That is a very tight deadline to turn out a critical app like this. Especially since I assume it wasn't just a single person doing the coding.
People don't realize that software is expensive and a custom built application is probably not the correct choice for a single-use product. I'm sure whoever was in charge felt that $60k was a quite generous offer to build this. In reality it's basically nothing.
I used to have acquaintances approach me and say, "Hey I've got this great app idea you could help me with."
The response I found shut them down real quick was, "Great. Do you have $100k lying around to get the first beta out the door?"