Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PyConZA 2014 - Writing Python Code to Decide an Election

PyConZA 2014 - Writing Python Code to Decide an Election

Earlier this year Ona was given three weeks to write the software that will tally votes in the Libyan elections and decide who wins and who loses. This is not something we could get wrong. We combined agile development with best practices in testing and QA to build an open source tally system that was well tested, accurate, and easy to use. We will describe a success story of iterative behavior/test-driven-development under extreme conditions. Did the structure of the data change the day before the election? Yes. Did we have the tests to ensure that our implementation changes would not compromise the system's integrity? Yes, and they didn't.

This talk provides a narrative to both Software Engineers and Tech/Product Managers describing why best practices are essential for any organization and any project of any size. We will provide the audience with:

Real world examples they can implement in their own workflow and organizations,
Insight into what succeeded (quick iteration with prioritization) and what was challenging (nothing being static),
Anecdotes and coherent arguments they can take back to their organization to advocate for best practices.

Peter Lubell-Doughtie

October 02, 2014
Tweet

More Decks by Peter Lubell-Doughtie

Other Decks in Technology

Transcript

  1. the problem • tally many votes from many districts in

    many elections • elections may span multiple district
  2. the problem • tally many votes from many districts in

    many elections • elections may span multiple district • each ballot has a 7-stage verification process
  3. only the essentials • what functionality must exist? • what

    tools already do some of that? • what if we miss something?
  4. a schema as a tool • decide how data is

    organized • shared reference !
  5. a schema as a tool • decide how data is

    organized • shared reference • scopes possible relationships
  6. a schema as a tool • decide how data is

    organized • shared reference • scopes possible relationships • it’s updatable
  7. issues and milestones • convert discussion to issues • decide

    prioritization through milestones • communicate to what will get done when
  8. do it 1. assign an issue 2. write tests for

    the issue 3. write code for the tests ! ! !
  9. do it 1. assign an issue 2. write tests for

    the issue 3. write code for the tests 4. issue a pull request ! !
  10. do it 1. assign an issue 2. write tests for

    the issue 3. write code for the tests 4. issue a pull request 5. review the code !
  11. do it 1. assign an issue 2. write tests for

    the issue 3. write code for the tests 4. issue a pull request 5. review the code 6. pass the CI
  12. do it 1. assign an issue 2. write tests for

    the issue 3. write code for the tests 4. open a pull request 5. review the code 6. pass the CI 7. merge and go to step (1.)
  13. automate speed • anything that is done twice gets a

    script • anything that breaks once gets a test
  14. plan to handle what you have not planned for •

    elections can span multiple districts
  15. plan to handle what you have not planned for •

    elections can span multiple districts • did not know until the first day of live testing
  16. plan to handle what you have not planned for •

    we changed the data model => south ! !
  17. plan to handle what you have not planned for •

    we changed the data model => south • we wrote tests => django-nose !
  18. plan to handle what you have not planned for •

    we changed the data model => south • we wrote tests => django-nose • we changed the code => travis-ci
  19. plan to handle what you have not planned for •

    we changed the data model => south • we wrote tests => django-nose • we changed the code => travis-ci • we deployed => fabric