Hasty Innovation: the Kind We Don’t Need
John Sebes
Today’s posting landed in my lap in the form of a note from election tech colleague and Pitt researcher Collin Lynch, as part of a discussion about the role of the Federal government (specifically the Election Assistance Commission, or EAC) in “fostering innovation” in the market for voting systems, and ensuring a “healthy market”. Well, of course, we think that there is plenty of room for improvement in voting systems, but there is a big difference between (for example) improved usability or reliability, and innovative changes voting system administration that require election officials to change how they do their job. But Collin hit the nail on the head:
Speaking as a software developer I think the cry for “supporting innovation” comes from two mistaken impressions.
- The mistaken impression that voting laws should somehow be concerned with the “health of the market”, that is, the EAC’s responsibility includes not only the stability of our democracy (difficult enough as it is) but also maintaining “healthy market” for the products of voting system vendors. This is a view that has caught on to some extent in defense spending and other areas but in my view a market exists soley to serve some need and artificially inflating that need, at best, tilts the market to no good end.
- The mistaken impression that the technology development process can be “stimulated,” especially when the market has real needs for problems to be fixed, problems that appear simple and therefore should be fixed quickly. For voting systems in particular, this is not true.
These are fundamental misunderstandings of how good systems development works and how it can be made to work. In the extreme I have seen purchasers of systems assume that programmers “can just work faster” without considering the costs of quality and stability this brings. This is a view encouraged by the (seemingly) breathless pace of .com development which of course ignores the long lead time many of these overnight successes have and the stability problems that result from alphas being rushed to market.
I couldn’t agree more. The last thing that we need in voting systems is encouraging vendors’ already-existing bent for innovative bell/whistle features that customers (election officials) didn’t ask for, and/or pushing for updated systems to be developed quickly and rushed through the regulatory certification and accreditation process. And while we at the TrustTheVote project are hardly in favor of foot-dragging, we do also recognize that quality, reliability, simplicity, integrity, and many other important qualities, fundamentally start with understanding what the customers need, and making sure that we build to those needs — and with the attention to quality and reliability that is needed to make it through the regulatory process as well.
— EJS