DZone Startup Series: Broadcastr's Part in the Future of Storytelling
The DZone Startup Series focusses on companies that are using Java at the core of their business to power their startup. Want to find out what drives these startups, and what happens behind the scenes? You’ve come to the right place.
Today we’re kicking off the series with Broadcastr, an Android and iPhone app that creates an intimate and immersive experience by unlocking pictures and audio relevant to your current location.
I spoke with Rick Mangi, the SVP of Technology at Broadcastr to find out everything I could about the startup.
Broadcastr was started a year ago by Andy Hunter and Scott Lindenbaum. They had been running a literary magazine for the past few years and decided to explore the "future of storytelling" in the mobile space. They got some seed funding and offshored the development of the beta version of Broadcastr.
Rick joined the team in October 2011, when when they realized that they had something good and needed some technology strength to bring it to the next level. Rick’s main task was to hire in a local development team, while the offshore team kept things ticking over until the end of 2011.
Rick believes that “offshore is not really a viable solution for startups” mainly because of the communication difficulties:
Communication is too important when you're working with a small team. There is no substitute for being able to turn around and have a conversation with someone. That said, we do spend a ridiculous amount of time IMing each other (since talking involves removing headphones).
The team is based in Brooklyn, NYC, a place that Rick considers to be “startup 2.0” in New York. The office has it’s own unique setting, in an old toy factory - one big room broken into a developer area and a business area, along with a small conference room and a lounge area.
I think what attracts startups to Brooklyn as opposed to Manhattan is not just the cheap (ok, less expensive) real estate, but it's also the fact that most people LIVE in Brooklyn. A lot of us bike or walk to work.
The Technology Stack
Broadcastr’s technology stack is Java on Google App Engine, which Rick has a love-hate relationship with. Java would have been Rick’s first choice as it's what he is most familiar with.
Until someone gives me a really compelling reason to use something else I'm going to use what I know best. The magic is in the idea, not in the tech stack. Java is the most mature tool for building web products on the market today.
Experience teaches us a lot of lessons, and Rick’s experience with Google App Engine is interesting:
GAE is another story. It's incredibly powerful, but it's also limiting. As long as you do things the App Engine way, it's great. It scales, it's fast, it's (usually) reliable and at the end of the day it's fairly affordable. SaaS means we don't need to worry about system administration which is a big win for a startup. We don't have to worry about server installs and costs as we scale, it's just a line item. However, as soon as you try to do something that doesn't fit into the GAE model, you're stuck and you can't do it. We've had to bring up a couple of EC2 instances to handle some administrative tasks and honestly, we might move to a full EC2 or Rackspace stack at some point.
My biggest complaint about GAE is their lack of support. Even with the "premier" service their documentation is weak at best and they don't like to respond to bugs or feature requests. They bring the same lack of transparency that they (rightfully) have for their search products to App Engine and it's maddening. We frequently find ourselves having to code around holes in their services or trying to reverse engineer the black box to figure out what's going on.
Groovy heavily features in Broadcastr’s stack, utilized for unit tests and administrative work.
It's fast and easy and it allows us to write services on top of our existing java stack without having to use web services or some other cross-language glue. We try to avoid groovy for server work because it's not as fast as pure java.
When it comes to scaling, Broadcastr cache as much as possible at the edge and in memcache. As most of the content is static, this doesn’t raise much of a problem.
GAE is blazingly fast and it will scale up with requests like magic. However, that scaling comes with a caveat, servers stop and start frequently and application startup time is a problem. We realized this early on and I had to ditch Spring, which for years has been my favorite framework. But all of that dependency injection means slow server startup time and GAE didn't play well with that.
The startup world embraces failure as much as success, so I wanted to find out what Broadcastr’s experience was here.
As far as failures go, it took a little while to grasp the NoSQL / GAE world and I definitely made a few mistakes early on trying to bring my old toolkit into this world, but fortunately I learned a long time ago that there is no place for big egos in software development and I stopped trying to fit a square peg into a round hole.
Getting Into The Industry At The Right Time
I spoke to Rick about his own education and experience: he graduated from college with a degree in CS and Sociology, right at the edge of the big boom, in 1995. He moved to NYC in '97 to join a .com technology consulting firm where he worked with a number of startups as well as larger media companies on backend technology, mostly with Perl and Java.
Since moving on from there in 2000 he spent time in a couple of startups, Wall Street and most recently MTV Networks before joining Broadcastr last October as the head of technology.