Culture / Development

This Week in Programming: Iowa Shows Apps Can’t Replace Institutional Knowledge

8 Feb 2020 6:00am, by

Amidst years of reports that foreign governments are in an ongoing campaign to influence and affect elections in the United States, what does Iowa (and Nevada) do but go ahead and hire a company that goes by the name of “Shadow Inc.” to build a smartphone app to help tally election results in the Democratic primary race. You could make this up, but a discerning editor would tell you that it is the stuff of B movies and the worst of Tom Clancy’s plot lines.

Well, this week the tale of everything that went wrong — and there’s just so much — is making the rounds on the internet, and the script doesn’t get any better after that first simple synopsis. I can’t help but be reminded of that time, a couple of years ago now, when the entire population of the Hawaiian Islands thought they had mere minutes to live after an errant click sent out alerts that a nuclear missile attack was on its way.

This time, while nobody immediately feared for their lives and those of everyone for miles, we have the first race of a long election season cast under a shadow of a doubt all at the fault of a disastrous app that couldn’t have done much worse if it tried. As Axios writes of the debacle, “this was essentially a playbook for how not to employ technology in an election.”

A story in Motherboard offers a detailed look at all that went wrong, finding that not only was there little to no testing done before primary night, the app was actually distributed via TestFairy, a mobile app testing platform for Android, and TestFlight for iOS, both of which are meant to circumvent app store restrictions (including security requirements) and offer developers a method for distribution during beta testing. That’s just the beginning, however. ProPublica, meanwhile, writes that “the IowaReporterApp was so insecure that vote totals, passwords and other sensitive information could have been intercepted or even changed, according to officials at Massachusetts-based Veracode.”

All that aside, there’s a Twitter thread that offers a slightly dissenting view on the whole thing, not looking at app distribution, security, testing, or anything of the sort — rather, focusing on our increasing tendency to rely on technology to replace institutional knowledge.

Justin Joque, the author of this brief thread that has made the rounds this week, further argues that “this is part of a larger conflict between bosses and labor, in which the bosses have deluded themselves into thinking that they can go it alone without the workers who are constantly fixing, patching and maintaining these complex systems.”

While you can go and read a slew of articles that in some sense just equate to a trainwreck that we can’t help but keep staring at, this thread and its responses offer an alternative view on the whole fiasco: that we’ve been taught that “there’s an app for that” and our knee jerk response to fix it with technology has been proven time and again to be a faulty one on its face.

Of course, there’s likely an argument somewhere in between that says that, with proper time, preparation, testing, hardening, distribution, what have you…you’ll still have an app that can be hacked. Did I say that? What do you think — is there an in-between ground here? Can we augment apps with institutional knowledge? Can we encode that same knowledge? Or are we leading ourselves continually down a path of technological despair?

This Week in Programming

  • HackerRank’s 2020 Developer Skills Report: It’s that time of year, for a variety of “State Of” addresses and reports, including the 2020 developer skills report by tech hiring platform HackerRank, which has churned out a number of headlines this week. Skimming those alone, we can learn that most developers know JavaScript, and most want to know Go according to InfoWorld, developers in 2020 learn via non-traditional methods such as bootcamps and YouTube writes JAXEnter, and there are, apparently, new generational gaps, according to iProgrammer. That last headline is particularly notable to me, because it appears that music and year born are not the true discerning factor of whether or not I fall into GenX or Z, but rather the fact that I learned to primarily code in BASIC and not C.
  • Java, C & Python On Top: While we’re here talking about polls and surveys and the like, the latest TIOBE Index is out, and DevClass notes that Java, C and Python tie up programming language top three… again, noting that C has remained in the top tier since TIOBE first started keeping tabs back in 1985. According to TIOBE, C has been on the rise recently, although Java remains on top, with Python wrapping up the top three. But you already knew that, right? Well, on the same and final note of rankings and surveys, StackOverflow has opened up its 2020 developer survey and it’s hoping to get enough responses to truly “represent everyone who codes.” And GitLab is getting in on the fun too, with its 2020 DevSecOps survey, which will run through the end of the month.
  • A Tale of Transition from Go to Rust: We look at these numbers partly because we want to know we’re heading down the right path, both in our careers and in our language choices, right? Well, this week we also find the tale of why Discord is switching from Go to Rust, which the company says “drastically improved the performance of a service by switching its implementation.” With a focus on improving performance for a particular service, the company found that Go’s memory model and garbage collector were causing large latency spikes. Rust, however, does not have garbage collection, and so the choice was made to switch. Of course, none of it is nearly that simple, but if you’re interested in the full details, the blog post offers many. One key takeaway: “Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.”
  • What’s Next for pkg.go.dev: The pkg.go.dev site, which acts as a central source of information about Go packages and modules, is getting some updates in 2020 and the Go team has outlined the next steps for pkg.go.dev in a blog post. The features to be added, they write, will “help our users better understand their dependencies and help them make better decisions around what libraries to import.” Some changes include a redirect from godoc.org, and the introduction of API access to pkg.go.dev.
  • More Details on the GitHub Actions API: We wrote of the introduction of the GitHub Actions API a week or two back, but there were few details available at the time. This week, GitHub has put out a blog post on how to manage secrets and more with the GitHub Actions API, offering some concrete use case examples on what you can do with the beta API. After reviewing some initial feedback, GitHub writes, they decided to focus on four discrete themes for the first iteration: reading workflow run and job data, managing repository secrets, downloading artifacts, and registering self-hosted runners. Read on for details.

Feature image by David Mark from Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.