Policy-Driven Design

Live from NASED, want to pass along a comment about the engineering realities of a Digital Public Works Project, in the midst of listening to Congressional staffers discuss what's up on the Hill regarding election reform legislation.  I just tweeted about the likelihood of making election day a federal holiday (its real and that should make our friends happy), but related comments on the panel sparks another observation.

Inasmuch as we're trying to focus on purely technical matters in search for excellence in trustworthy voting systems, it is becoming increasingly clear that we will be compelled to live up to what we quipped a couple of years ago: that "we're a bunch of technology and policy geeks working to restore trust in how America votes."  Emphasis may be increasing on the latter: policy geeks.

In order for adoption (to become a reality) of open source, open data, open process and open standards based voting technology it is increasingly apparent that we must incorporate policy issues (of how elections systems are viewed, adopted, and deployed) in all of our design work.

In fact, it would appear that the TrustTheVote Project will also need to incorporate "policy-driven" design considerations inasmuch as we're trained on "user-experience driven" design and "test-driven" development, using (at once) high assurance computing engineering discipline married to the agile processes of open source development.

Well, "daunting" seems to be creeping into my voting technology vocabulary.  No one said change is going to be easy.  Who said that?

GAM|out