I have been reading The Black Swan : The Impact of the Highly Improbable by Nassim Nicholas Taleb (a.k.a. NNT) and been thinking about its impact on some of the assumptions that I have made.  One of the main points is how often accept as proven fact theories which ignore silent evidence.  Software professionals fall for this kind of logical failure all the time.

Let’s consider a theory that ignores silent evidence.  I plan on voting for Barack Obama for president.  If you were to make conclusions from a poll that consisted ONLY of asking me who I would vote for, it would be logical for you to conclude that Obama is going to overwhelmingly win both Pennsylvania and the national popular vote. These predictions may very well prove to be accurate and you might be hailed as a tremendous prognosticaltor.  But most serious analysts would mock you.  They would be correct to do it.  Because of the miniscule sample size, your poll does not accurately reflect the size of the entire population that will be participating in the election.  The "silent evidence" are the opinions of all the voters who have NOT been polled.  A good pollster mitigates ignoring the silent evidence by trying to come up with a representative sample; the idea being that if you can get a large enough sample broken down by representative demographics, you can make a reasonable prediction.

So what’s the point?  Let’s consider another example.  In a famous essay, Paul Graham talks about the advantage of using functional programming languages when creating your startup.  If you haven’t read the post, I highly recommend it, it is well written and thought provoken.  However, it clearly ignores the silent evidence.  Graham takes his singular experience and makes a conclusion based off it.  But consider the silent evidence:

• How successful of functional language based software startups versus all software startups.

or a slightly different cohort

• How successful were functional language startups during 1995 (when ViaWeb was started) versus all software startups founded during that year.

With both these cohorts, we should probably include in the sample those kitchen table companies that started but never shipped a product.  Maybe many functional language startups fizzle quickly out and only the ones with really great ideas survive.

Of course, I could just as easily make the argument that statups that have two really, really smart co-founders who have impressive technical and business savvy and are starting their company in an exploding market have a much better probability of success than companies without those advantages.  My theory is no more right or wrong than the one posited above, we both are ignoring the silent evidence in positing our

My point is not to say Paul Graham is wrong about startups and functional languages.  He is a smart guy and has accomplished much more than I.  The Beating the Averages post was just the first one to popped into my mind while reading Black Swan, I’m sure I can find countless other technical articles.  But I do want to introduce some skepticism into the reading of his post and many other software legends.  When critically reading a book, article, blog posting, consider the silent evidence before making judgement on the theory.

Popularity: 45% [?]

Bookmark to:

Hide Sites

I’m on a hot streak tonight… Another comon problem that I have had to solve recently is how to attach a build number to files that are being generated out of an Ant build script.

We have developed a versioning scheme (inspired by http://geekswithblogs.net/emanish/archive/2006/09/25/92219.aspx) for our releases where our release are named <major>.<minor>.<revision>.<build>. So a valid build number might be 1.18.2.1077. This means it belongs to the first major release of the software, the eighteenth minor version, it is the second attempt at a release for this minor version (usually bug fixes), and it is related to the SVN revision number 1077. Any time we are doing a build we are tagging in our Subversion repository to keep the build number tied to the tag. When I build a release, I want my artifacts to look like to look like this: app-1.18.2.1077.ear.

There are a few ways to do this, One way that I considered was to just include a property or Subversion tag in the build.properties file. But I did not want to maintain it and I have always loathed the auto tags that were available in CVS.

My second option was to use the <svn> Ant task. While this will probably work, I have varying degrees of success using the Java SVN library, especially when connecting to Subversion over SSH as we are doing for this application.

So, I decided to go with using the task in conjunction with svn info and svnversion to set the full.build.version property to the current release number. This assumes that the repository checked out is of the format svn://REPO_NAME/tags/<MAJOR>.<MINOR>.<REVISION>

<exec outputproperty="build.current.revision" executable="svnversion">
         <arg line="-n -c" />
         <redirector>
           <outputfilterchain>
             <tokenfilter>
                 <replaceregex pattern="^[0-9]*:?" replace="" flags="g"/>
             </tokenfilter>
          </outputfilterchain>
        </redirector>
</exec>
<exec outputproperty="build.current.version" executable="svn">
  <arg line="info" />
  <redirector>
  <outputfilterchain>
  <linecontainsregexp><regexp pattern="^URL:" /></linecontainsregexp>
   <tokenfilter>
     <replaceregex pattern=".*\/([^\/]+)$" replace="\1" flags="g"/>
   </tokenfilter>
  </outputfilterchain>
</redirector>
</exec>

<property name="full.build.version" value="${build.current.version}.${build.current.revision}" />

I’m sure that I could have gotten the revision from the svn info rather than svnversion, saving a command, but I wasn’t inspired enough to do it. Maybe when I have more time.

Popularity: 91% [?]

Bookmark to:

Hide Sites