Monday, April 20, 2009

NBA Data Analysis

Awhile ago Mark Cuban posted an interesting break down of some possible inequalities in the NBA scheduling. Basically some teams had more back-to-back games and more set of 4 games in 5 nights. The assumption was that teams would do worse with less rest time.

I was interested to see if that assumption was true. The best data I could get was from Department of Statistics, University of Munich, and the SFB386 which has the entire 95/96 NBA season broken down game by game.

I wrote a simple app to analyse the data (run the test NBATests.DataSetTests.ParseTest to re-run the analysis). The results of the test are in the spread sheet stats.xlsx in the zip file. In that season there didn't appear to be any 4-in-5 sets. That must be a new invention by the NBA.

The numbers are interesting. Overall the win percentage for the league when playing the second game of a back-to-back set is 44%. When taking into account a team's overall win percentage for the season the average difference in win percentage between games that were back-to-back and those where the team had a rest night before was 7%.

8 teams did better in back-to-back games, Miami led the way, their win percentage was 15% higher in their second game.

Atlanta on the other was abysmal, their win percent dropped 39% when they had to play two games in a row.

I had the thought that better teams might be better because of their bench and thus would fair better in back-to-back games because of their depth but this doesn't appear to be the case. The r-squared value for win percent plotted against win percent difference in back-to-back games was only .015.

So overall while some teams appear to get better in back-to-back games overall I think the assumption that it is a disadvantage to have more back-to-back games is a fair one.

There are all kind of other ways to slice up the data that I didn't do but someone should:

  • Exclude games where both teams are playing back-to-back.
  • Factor in home and away win percentages and not just overall win percentage.
  • Doing some kind of qualitative analysis on the depth of the teams that year to see if that plays a factor.
Also if anyone has a data set(s) for more recent years send them over and I'll plug them in and see if these results hold year over year.

Thursday, April 16, 2009

TFS InvalidProgramException (or why software you need to install is stupid)

We are trying to includes some code that we keep in TFS source control into our builds. We also use code from AccuRev and SourceSafe. So we wanted to keep our existing build process and just have it include the TFS code instead of moving to an entirely TFS based build system.

So, like with any new tool we are including in our build process, I install it (in this case the TFS SDK) locally on my machine, get the DLLs from it and dumped them into our externals folder in AccuRev. Then I coded up the TFS integration piece and wrote some tests and everything looks like it was going wonderfully.

Then I tried to do a build on our build farm. The first call to TFS (TeamFoundationServerFactory.GetServer in this case) yielded:
Unhandled Exception: System.InvalidProgramException: Common Language Runtime detected an invalid program.
at Microsoft.TeamFoundation.Client.TeamFoundationServerFactory.GetServer(String name)

what the heck? Turns out the most common reason get this error is the TFS and x64 machines don't play well together. But in my case it was because I didn't have TFS installed on the machine I was tyring to run it on.

This is a huge pain in the butt. We build lots of versions of our software, we need to make sure that 3 years from now when we need to re-build the version from toady it will work fine. But if I have to install it on the machines instead of checking it in to source control this becomes very hard. What happens when Microsoft release an SP that changes something? What happens when TFS 2010 comes out and isn't able to install side by side with the 2008 version?

Please, please, if you are making software, especially software used for software development, make sure it can be deployed via xcopy.

Another case of this is Dofuscator, we use it now on one machine, we are pretty happy with. We would like to scale it out to all of our machines but you need to install it and register it on each machine to make it work. This is a deal breaker for us. They just a lost a bunch of licences.

I get that some programs want to control your usage of their product. But allow people to by a site licence and then deploy that via xcopy. Its more work but it will make your customers a lot happier.