As I mentioned yesterday, I'm releasing a bunch of new college basketball recruiting features this week in honor of the upcoming basketball season.

Today, you can find my analysis on which freshmen classes have been the most impactful and most disappointing. The methodology I used was pretty simple, but the conclusions are interesting.

Posted by Robbie | Permalink | Comments

For those that have been following StatSheet from the beginning, you'll know that I started with college basketball. Now StatSheet has become the #1 site on the web for college basketball stats. With the new season just a week away, I decided I'd add some new features to mark the occasion. The theme is going to be college basketball recruiting.

You may be familiar with the HS Basketball section. Over the next week I'm going to add a bunch of new pages that analyze the Top 100 recruiting classes since 1998. I'm going to break it out by team and conference. I'll show which players went from Stud to Dud. Which classes were the most impactful, most disappointing, etc.

To give you the first taste, I just put up the "Best and Worst" page. It's a little raw, but it will give you an indication for which classes produced the most wins, losses, NCAA tournament game appearances, draft picks, etc. Expect more to follow soon...

Posted by Robbie | Permalink | Comments

I'm pleased to annouce that StatSheet has been selected as one of the Demo Showcase companies for next month's Internet Summit. In addition, I've been asked to speak on the Twitter/Real-time panel, which I think could be one of the most interesting panels of the conference. I bet I'm the only panelest that's actually been banned by Twitter! I also have plenty to say on the topic of the real-time web since I'm in the middle of working on my own sports-related real-time website.

I'll do my best to man the StatSheet booth at the conference so please stop by and say hi.

Posted by Robbie | Permalink | Comments

I know this post will be heretical to some in the software development community, but that's why it's important to write about it.  In short: I don't do any automated testing of the StatSheet Network sites, but rely on GoogleBot to notify me of bugs.

A little background before I continue...I incorporated StatSheet in June 2007.  The company has been a single person entity since (and bootstrapped).  I've done all the programming and design with the exception of logos which I've outsourced using services like 99designs.  A recent count shows the StatSheet codebase is well over 200,000 lines of code for all backend and frontend code.  That's translated to over 1.5 million unique URLs I'm submitting to Google via sitemaps that cover statsheet.com.  

Early on I had to figure out how I was going to test this beast of a site I was creating.  Currently StatSheet covers College Basketball, NBA (partially), College Football (partially), and NASCAR.  I have historical data for many seasons.  That means lots of players, teams, coaches, conferences, etc.  Lots of permutations of what stats are available with those players, teams, conferences, etc.  I track thousands of stats and attributes across those sports.  It is statsheet.com's job to make that information available in easy to digest ways.

Instead of writing a bunch of test code to go through all the various permutations that could result in errors on the front-end, I found GoogleBot (Google's web crawler) was doing a pretty good job of scanning the whole site in a timely manner.  I set up code on the front-end to email me anytime there is a Server Error.  I found early on that when I'd push out new changes, GoogleBot would find obscure bugs with infrequently visited pages much quicker than I (or even my users) could.

So I abandoned any formal attempts to automate testing of StatSheet.com (at least for now).  GoogleBot is constantly scanning the site and notifies me when it finds bugs (via the email on Server Error).  That means I can keep moving full speed ahead writing new code, trying to add more features and visualizations of the data without spending a lot of time writing test code.  I've found this works well in the lean, single-person company mode I'm currently in.  You can avoid much of the formality of software engineering if you are the only person that ever touches the code.

What about when developer #2 joins StatSheet?  That will be a great!  But it also means I'll need to introduce more formality.  We'll likely need to introduce some automated testing at that point.  And yes, it will be a bit of a pain to go back through and write tests.  But unless I can get StatSheet to the point where I'm bringing in enough revenue (or if I decide to raise outside funding) it doesn't make a difference how much test code I've written.  In these early days of the company, the important thing is getting the site as functional as possible and worry about testing later when it becomes more important.

Posted by Robbie | Permalink | Comments

About StatSheet.com

Have a suggestion?
Let me know