Debugging Politics: a software engineering take on it

In less than two hours, I will go to the Debug Politics hackathon. Here are a few thoughts I put together in haste.

Debug Politics is a hackathon for anyone dissatisfied with the 2016 election cycle. Transform your dissatisfaction into a unique idea. Let’s use our talents as developers, designers, and technologists to find innovative ways to make a real difference.

This is very exciting and aligned with Obama's request for each of us to be the "anxious, jealous guardians of our democracy".

I am a computer scientist and "bug" and "debugging" have a special meaning to me. I want to make sure that everyone attending the event can benefit from what we have learned in the computer science space about bugs and the best ways to avoid and treat them.

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. [source: Wikipedia]

It is not always clear when this is a bug

Bugs are not always easy to spot. Some of them are obvious and famous like the Pentium bug where the computer was doing arithmetic computations wrong or the Heartbleed bug that was making SSL/TSL not as secure as it should be.

I also remember my iPod shuffle. I was always curious about going into shuffle mode and pressing play, then next, then previous, then next. Should I get the same song twice or should I get two different songs. In the first case, the sequence of songs to be played is shuffled once and for all, and you only navigate between songs in the sequence; for the second case, the reshuffle happens every time.

Depending on your understanding of the correct behavior, you see a bug or a feature.

The life cycle of a bug

For people who have done some software engineering, the life cycle of a bug usually looks like this:

  1. find the bug
  2. report the bug
  3. triage the bug
  4. assign the bug
  5. fix the bug
  6. check that the bug has been fixed
  7. push the fix to production
  8. close the bug

Finding the bug can be hard. Some bugs only occur in very rare situations, e.g. the Pentium bug.

Reporting the bug is not as easy as it sounds. The art is to capture the minimalist behavior that demonstrates the bug, to make it easy for the people fixing it to identify the root cause of the bug.

Triaging the bug is crucial. First, some reported bugs will be flagged as non-bugs. Some bugs will never be fixed because they are too hard to fix or they occur in such rare cases that fixing them is not cost effective. Triaging also includes adding a level of priority (e.g. P0, P1, P2, P3, P4) to the bug.

Assigning the bug means finding the right person/team to fix the it.

Fixing the bug means what it says. This might take 5s or take forever. Some bugs are never fixed.

Then you need to check that fix actually makes the bug go away. This is not as obvious as it sounds. You should also make sure that fixing the bug does not create another bug somewhere else.

Once the bug has been fixed, the fix needs to be propagated to all systems running the code.

Once all of this has been done, the bug can be closed.

Debugging tools

Here are some tools that helps with avoiding bugs and diagnosing bugs.

  • debugger
  • tracer
  • unit test to test behavior and avoid bugs
  • formal specification
  • memory leak tracer
  • type systems
  • version control systems
  • etc.

Show me a bug in politics

Now let's move to politics. Here are some examples I could think about possible bugs in politics. But are they bugs or not?

  • a new president being elected with less than a majority of the votes
  • most congressional districts not being contested because of gerrymandering
  • a mayor doing a 3rd mandate when there is a two-term limit
  • a journalist sharing questions with a candidate ahead of a debate
  • cabinet members being appointed and not elected
  • judges being elected and running campaigns
  • an election season that lasts almost two years and costs more than $1B
  • a president not being able to appoint a Supreme Court Justice
  • super-delegates
  • the unequal voting power and winner-takes-all
  • the 2 party system
  • filibuster
  • spending one hour in line to cast your vote
  • voter registration
  • a US election where 46% of voters did not bother to vote
  • Election Day not being a day-off while Columbus Day is.
  • ADD YOUR OWN HERE

Debugging tools for politics

What would be a good set of debugging tools for politics? Here are some ideas.

  • open data for voting records of all elected officials
  • type checker for legislation (to make sure a new law does not conflict with an existing one)
  • LinkedIn-like tool for elected official to detect conflicts of interest, nepotism, etc.
  • money tracking tool

Conclusion

"Debugging Politics" is hopefully not just a gimmicks. We can apply a similar principled approach to the one we are using for software engineering.

The big caveat I see though is that debugging software requires access to the source code and I am not sure how this translates to politics. Probably open data.