First of all, All results are safe, recorded, unchangeable. There are no inconsistencies, there are no discrepancies, there have been no manipulations of results. There is nothing to panic about.
At each caucus, the results were recorded. Those records exist on paper form. These results are validated by various candidates agents. Many others would also have taken photos, or jotted down for their own campaign data. These paper records would arrive at destination as planned later.
The said “inconsistency” is in reporting. Meaning, not everyone was able to report the results. Inconsistency is not in the results, just the reporting mechanisms.
There has been no hacking, no changing results, no intrusions. The delay in reporting has been due to failure of the fast information internetwork based mechanism that is used to transmit the record from each location. The transmission of the results from each location required using backup mechanisms. The backup mechanisms were, phone in the results, submit photos of paper copy records of results, or drive (catch a bus, grab a lift) and deliver the paperwork. Do not take my word for it. Hear it straight from Rachel here https://www.msnbc.com/msnbc/watch/state-democratic-party-finds-inconsistencies-in-reporting-of-caucus-results-78059589765
Please, do not cast aspersions on the results. Some very distressed people are trying to drive in the miserable weather to deliver reports.
There was some sort of cockup. And the the actual cockup is a project management failure. Information Technology projects are notorious for their delays and overruns and cockups to start with. Iowa caucus results reporting process, from the information that is publicly available, is a classic example of Information Technology Project Management failure. This is what differentiates the professionals from amateurs. This is a perfect illustration of differences between people who use technology for casual, social, non-critical purposes and people who support and implement technology and application deployments.
On a sidenote, this morning a few of us of Asian background in our chatrooms and boards are seeing, something along the lines of
“We are taking american jobs? A homegrown white American who went to an American school, and barelys holds a GED thinks someone from asia with Degree in the right field and experience stole his job?”.
“Brown people huh, they take the jobs white people will not do, and they also take the jobs white people can not do.”
So lets look at this project management failure a bit more
What do we know so far?
- App (Application) to be used was still being deployed, people were still downloading app on the day itself.
- Application was showing error when it was time to transmit the results to HQ.
- Some publicly known errors so far
- “Unknown protocol. The address specifies a protocol (e.g., “wxyz:??”.) the browser does not recognise, so the browser cannot properly connect to the site”
- Some pin numbers/logon problems.
- Some Error messages were very verbose (detailed)
What does this mean?
- Social/Political failure: Lack of communication. Prior documentation and training manuals for caucus captains as well as media pack should have contained information on what was the backup plan for the process should something go wrong. There should have been adequate prior notification that if teh new thing that was beign tried did not work out, the results would still be available although just a couple of days late becasue results would have have been needed to be transmitted through alternative methiods. The alternative methods should have been adequately distributed. Mechanisms should already have been in place to reassure the public about integrity of results (data). The event manager for the caucus should have been a bit more on top of the ball and not relied on some new fancy stuff.
- There was no field test of the application. App might have been written and the backend services setup. But not having done proper field test many issues that come up were not spotted. With 1700+ deplyment of the app, even a basic field test would have highlighted many issues. This would have highlighted application failures, connectivitry issues. More people on the test the better.
- There was no rehearsal. Given the political and social importance of the event that had been drummed up (fairly or unfairly) a rehearsal should have been done. A rehearsal would have highlighted many more issues. Ideally there would have been repeated tests. This would have also given information on what could go wrong and how to deal with it. Rehearsal would have also load tested the process of transmission of report. Were there connectivity issues, were there excess load on back end systems that collected the data, are there any authorization, permissions issues, are there any account issues, can the backend handle the volume of connections being made.
- Applications should have been deployed to every device/computer/phone/tablet that was going to need it, weeks in advance. People should not have been just downloading the app immediately before the caucus event. This is extra sloppy.
- End user issues which surface only when you have lots of people doing many unimagined activities would have given a better idea of how many different ways peoples using the app could result in errors. People mistyping pin numbers/passcodes once too many times and getting their accounts locked out is something we all have ran into.
- The detailed (verbose) level of error messages displayed on screen indicates that a developer version of app was deplyed instead of an end user version. A developer version would have a lot more data on display about what the app is doign and how it is doing which generally is useful for developers to track it to iron out design and coding issues.
All these failings are project management failings. These are neither failures of the election nor degeneration of integrity of results. Lets hope that they do a better job in Nevada.
Lets avoid conspiracy mongering.
That brings me to a book written/published in 1997. It was written by Tony Collins and David Bicknell titled Crash (10 easy ways to avoid a computer disaster)
Tony Collins is a world famous (okay, world famous in a small circle of us people who specialize in computer/IT project disasters) author whose research/study of some big IT crashes. It details 10 simple things to avoid an IT disaster (technical or public relations).
The book text examines in detail the case histories of many of the worst computer crashes and software failures, revealing the lessons to be learnt from each. The same ten factors recur in most, if not all disasters. Jargon-free, this book provides ten ways to avoid most computer disasters. For those interested, second hand copies are very cheap at amazon
https://www.amazon.co.uk/Crash-Easy-Avoid-Computer-Disaster/dp/0684816881
This book should be a gospel for all IT people no matter what job they do.
No I do not get a commission. I wish Tony would make another print run, it would make this years gifts for people so much easier.