Hacker News Reader

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.

Why they can't just do a https website with login is beyond me.

Why an App? We all know there's nothing in it but boilerplate.

Would it matter? You've still got to build it, the cost would be (roughly) the same.

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.

A large amount of the cost (perhaps most of it) isn't in building the software, it's in working out what they need.

Yes, a webapp will cost less. But if the vendor did this bad a job on an app they probably could do just as bad on a webapp.

Changing tech wouldn't have solved the problem for this vendor.

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.

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.

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.

From my experience with volunteers in different non-tech areas I have doubts.

If they can't open a web page they also are incapable of doing the math required on the sheet before sending the results.

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?

How haven’t PWA disappoint you

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.

They probably could have done it in google forms for free. It’s absurd how much they over complicated it.

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.

I don't think this is a failure because an iOS app was delivered instead of a website.

You can't update an iOS app as quickly as an website, unless it just request a view, which is even worse - just open it in safari/chrome.

Looks like someone put wrong test headers in there, for what it does, the App is 26MB.

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.

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.

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.

Yea, exactly. The stupidity is mind boggling.

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.

$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.

With $60k, they need not even be volunteers.

"...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..."

https://www.nytimes.com/2020/02/04/us/politics/iowa-caucus-s...

Security concerns? The same article states "the app had to be downloaded by bypassing a phone’s security settings" (emphasis mine)

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.

I think that's pretty much what I wrote in my comment. Agencies bill through the roof yet the devs get pennies.

The LA Times reports two Dem state parties, Iowa and Nevada, each put in $60k. Still clearly inadequate.

https://www.latimes.com/business/technology/story/2020-02-04...

Edit: Nevada has since said they will not use the app and are looking at backup options

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.

> 70K is the median programmer income in the US. (Based on a very thorough let's look at the first thing Google regurgitates!)

BLS, which while not perfect has far better data than most other sources trying to do this independently, says $84,280 in 2018.

https://www.bls.gov/ooh/computer-and-information-technology/...

> 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.

That same link has "Software Developers" at $105,590/yr[0]

[0] https://www.bls.gov/ooh/computer-and-information-technology/...

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.

They hired a lot of fresh devs from bootcamps if you checked the company page on LinkedIn. I would not be shocked if they really were that cheap.

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. 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 it was probably standard gross misunderstanding by non-technical people of what is hard vs what is easy.

60k is absurdly low. You get what you pay for.

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.

Only four states use caucuses (IA, NV, TX, CO).

2(ish). CO is a regular primary in 2020 (post prop 107/108 in 2016). TX democratic party no longer uses caucus.

Several US territories and other states[1] hold democratic caucuses of one form or another, but are less notable due to timing/delegate count.

[1] https://www.nytimes.com/2020/02/04/us/politics/what-states-c...

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

For 2020 in the Democratic nominating process, 3 states and 3 territories, actually: IA, NV, WY, American Samoa, Guam, and the Virgin Islands.

> 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.)

I heard the same thing in my morning radio program, it was NPR but I don't know what program.

That's actually a lot of money in an Indian context. Although outsourcing to another country might raise other kind of political problems.

A simple RESTful mobile-friendly web page could have handled this easy. What were these people thinking?

I think that realization is something that comes with experience, and I'm guessing these people had very little real experience.

The company was co-founded by a Google alumna.

That doesn't mean as much as you might think.

Working in the depths of google and running a company are two very different things.

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.

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.

Maybe but I would guess that none of those factors were even considered.

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.

I found this which has some specifics: https://www.cnn.com/2020/02/04/politics/iowa-caucus-voting-a...

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.

The two founders of Instagram spent $65k (out of $500k they raised) to launch the very first version of Instagram in 2010 [1].

[1] https://lnns.co/8zhgtOF0YCo

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.

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.

So what? What's your point?

That they should have used Django for the backend :-)

> 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.