## Monday, November 28, 2011

### Reboot!

I'm back, and the blog has a new name: Assume the Opposite.

It's been a long time since I've written anything here, primarily due to the lack of comment support in the home-grown solution I was using: I wanted feedback! As time passed it became clear that I wasn't going to get around to adding comment support any time soon so it was time to find an alternative platform. So after much fiddling with DNS and Blogger here we are.

Why “Assume the Opposite”? Proof by Contradiction is a standard mathematical technique where you assume the opposite of a hypothesis and follow the ramifications until you reach a contradiction. If you reach a contradiction, you have proven that your original hypothesis is true.

However, an inability to find a contradiction can also be illuminating. A classic example of this is Euclid's Fifth Postulate: for two thousand years mathematicians tried to prove that it could be derived from the other four postulates, or convinced themselves that they had derived it via other "simpler" postulates. It wasn't until 1830 that two mathematicians independently assumed that it was false and found that you could build a completely consistent geometry around that assumption (now called Bolyai-Lobachevskian geometry after those mathematicians). Einstein's general theory of relativity, which thus far seems to describe the universe well, postulates that space is curved and therefore Euclid's Fifth Postulate does not accurately describe the world we live in.

Now, computer science (and technology in general) is not mathematics: computer programs exist to enable the end users to Get Something Done, and computer source code is consumed as literature by programmers in addition to being evaluated deterministically by a computer. Nonetheless, I find assuming the opposite of my beliefs to be useful tool, not to prove them true, but rather to prove them false. Agile methodology exhorts us to Do the Simplest Thing Possible. When I find myself thinking “We'll definitely need X” (for example, we'll need a relational database), assuming the opposite, exploring where the issues might lie if we didn't have X, frequently leads to greater simplicity. Perhaps we don't really need X (a simple file would do), or we only need a particular aspect of X (a NoSQL database would work).