Boy, That Escalated Quickly

Technical Stakes in the Ground

Now that I had begun a side project building an app to search secondary ticket markets for sports tickets, I had to come up with a plan.

This started as a project to enhance my development skillset, so the first priority was to learn some new technology.  And because I would only be working on it part time, I had to allow for slow pace and the need to be efficient with the time I was going to have available.

First, I needed to choose a cloud platform.  At that time (2013) Google allowed for indefinite free usage, within limits I knew I was not going to exceed for more than a year.  I wouldn’t have to worry about reaching any milestone before a free trial period expired.

From that choice followed several others

  • Learning NoSQL was a primary driver of this project, so Google Datastore was an obvious choice.
  • Google APIs for data access, user management, REST endpoints. This meant tight coupling to the Google Cloud platform, but less time to get running.
  • Google MapReduce
  • Java for the back end. I stuck to the language with which I had the most experience and could be the most productive.  The temptation to try Python here was strong, but I had to be pretty efficient if I was going to make real progress on a part time basis.

Who’s Driving This Thing

With the technical stack choices in place, I could now design an application to incorporate these elements.  Is this backwards?  Absolutely.  The problems being solved by the application (in this case an earthshaking ticket search solution) should drive the tech choices.  But I had to balance that against my side project goals, which came first.  I knew that at some point this might cause me problems if I wanted to make this a commercially viable product, but I would deal with that when it arose.

Building It

It took about six months of starts, stops and restarts to build the first set of features, but I ultimately got something running that would search for any NBA team’s home games against high quality opponents.  And every morning it would send an email with results.  I remember the satisfaction of seeing that first email arrive right on time, with links to exactly the kinds of tickets I would buy.

The Nets have actually played some good basketball in Brooklyn.

Looking at that first email now, I am struck by 2 things.  First, it’s interesting how even the most primitive plain text email can give a real sense of satisfaction when you are building something new.  But more than that, I can’t believe that a mere 4 years ago the Nets had a winning record.  How times have changed.

Taking Stock

Reaching this milestone offered a good opportunity to look at how my technology choices had worked out and consider what the goals of the project were moving forward.

As it turned out, many of my technology choices were not ideally suited for the needs of the application.  For one, my data model would have fit into a relational model quite naturally and I was never going to have storage needs at internet scale.  So the scalability benefits of NoSQL options were giving me no benefits.  Conversely, adding new features was proving to be difficult in cases where joining within the data model was necessary.

Some of my choices were not as obviously mismatched with the app I was trying to build.  MapReduce even solved a real problem for me.  How could I search tickets for a sizable user base when the ticket vendor only allowed 6 API calls per minute (yes, per minute)?  I simply could not afford to make any redundant calls if I was going to be limited to such a low rate.  If I wanted a daily search to find Phillies tickets behind home plate and you did too, the system would have to share the results of a single API call with both of us.

MapReduce allowed me to map users preferences to individual games, then reduce to a single ticket query per game.  Conceptually, it was exactly what I needed.  But in practice, it brought a computational and data storage overhead that was disproportionate with my specific problem.  I was using a sledgehammer to swat a fly.

Fork in the Road

At this point I had to make a decision.  Do I continue down the path of deepening my understanding of the technology I started with, or do I commit to the path of trying to make this commercially viable and start making technology choices based on the requirements of the application?

I chose the latter and never regretted it.  I had learned enough that the goals of the side project had been met, but it looked like this ticket search application could carve out a niche within the secondary ticket market.  It was time to focus on that as the one and only goal.

Lessons Learned

I was surprised by how quickly the tension escalated between my side project goals and the commercial goals.  In fact, it was clear after building only the initial set of features that I was going to have to choose one or the other.  And ultimately, with the exception of Java as the primary back end language, I abandoned every other choice within a year.  As a result, I ended up doing a lot of refactoring and rewriting.

A side project may seem like a good launching pad for a commercially viable application, and in some cases it may be.  However, if you prioritize technology choices over the business needs of the application, you may end up where I did: throwing out a lot of your work and starting from scratch.

Leave a reply:

Your email address will not be published.