2 min read

Burden of Proof


I've always found solutions that are sort of obvious, but no one really notices them right away, interesting.  Let me give you an example.  One of my favorite compression algorithms is the ASCII compression algorithm.  This algorithm takes the 8th ASCII character and stores it in the 8th bit of the previous 7 ASCII characters.  This algorithm works because ASCII characters do not make use of the 8th bit.  It's simplistic, and gives a really bad compression ratio, but I like it because it seems like the sort of thing that was just hiding in plain site.  So when I saw the Bits of Evidence presentation at Dev Days it really stuck with me.

He started by pointing out some interesting facts in history but it really picked up when he brought up the following quote:

"[Using domain-specific languages] leads to two primary benefits.  The first, and simplest, is improved programmer productivity...The second...is...communication with domain experts"

-Martin Fowler (IEEE Software July/August 2009)

Now it wasn't the quote that I found interesting.  It was the fact that the presenter pointed out that there isn't one piece of proof offered up in this quote.  This is just a really intelligent person saying what he thinks is true, but there are no studies that have been conducted to prove that what he is saying is actually true.  He went on to point out that a lot of what we do concerning the process of software does not have any proof behind.  Without that proof, we have no way of knowing if what we are doing actually works.  It's an interesting point, and if we look at how other industries study there businesses, maybe it is about time that the software industry start to look at the way that software is created.  I'm just surprised that it has never really been questioned before.

After thinking about this presentation a little more, I realized that it reaffirmed the direction that Crank is taking with it's product.  Brian, Jason, and Thomas have a lot of experience dealing with customers who have had UI issues.  They noticed common themes, and solutions emerging from those dealings and they used that information to create a product that can expedite the process.  I think that classifies as a life study.