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 has gradually grown from one iPhone developer, Illya Lyashevsky, to additions like Mark Harris, a backend Java developer who is also strong in Android development, and Todd Kennedy, the resident JavaScript guru. This gives the team a strong foundation in the main technologies, but there’s always room for more - another iPhone developer who also has strong Java skills, and “the dynamic duo” - freelancers working on frontend and Android development. Straight away you get the impression that this is a small, strong, tightly knit development team, ready to react quickly.

The Location

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.

Lessons Learned

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.

It was a great time to be in the industry because all of the technology was so new that you pretty much had to understand the full stack in order to get anything of scale to work correctly. You couldn't *just* be a java developer, you had to understand unix, apache, databases and javascript because the entire stack was flaky and you had to be able to debug every element of your application.

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.