TopCoder style crowdsourcing for startups

Back when I was in high school in 2001, one of my computer science classmates introduced me to TopCoder, and there was something about it that I instantly loved. I was very competitive back then both in sports, and in the classroom, and the ability to compete in 45 minute algorithm programming contests felt like the perfect competition for someone who was experiencing a new found love for computer science. The way that a competition worked was that TopCoder would present everybody with three programming problems (easy, medium, and hard), and everyone would work for 45 minutes to submit solutions. If your solution was correct, you’d get points based upon how quickly you submitted, and your ranking would move up or down accordingly compared to other people on the site.

As someone who was young, and very new to computer science, the best I ever did back then was average. I’d occasionally be in the running for a cash prize of some sort, and I’d also occasionally deal with looks of shock and disbelief when I’d tell my buddies that I was staying home on a Friday night to participate in a “programming competition.” It was well worth it though, as nothing taught me more about algorithms and programming during those early years than working through TopCoder problem statements. As I moved on to college, and begun moving away from TopCoder’s compiled languages more towards agile practices and scripting languages, I stopped competing in the competitions frequently. Though I always had an interest in what the company was up to.

Fast forward to 2010. The company not only has algorithm programming competitions, but there are also design competitions, software development competitions, and categories for testing suites and marathon matches. They’ve turned themselves into a crowdsourcing platform where sponsors can submit components that they’d like designed, built, tested, and they attach bounties to each task. Competitors submit their best efforts, and the companies pay the winners the prize in exchange for using the components.

I haven’t used the new platform enough to how well this ends up working out for programmers, designers, and the sponsors, but it appears that in the world of big-co, big-money, long-dev-cycle, and compiled languages, Topcoder may be an easy and efficient way for a project manager to outsource a small project that they don’t have the time or ability to deal with on their fixed in-house team.

It’s a shame that this model doesn’t quite carry over to the agile development world. When team members have to wear many hats, and you don’t have the luxury of a multi-month plan/design/architect/build/test cycle, it’s difficult to crowdsource your components. Sites like 99designs, elance, and odesk can help fill empty needs, albeit at a pretty high cost of uncertainty about what you’re going to get for your money. I’d love to see a startup build a TopCoder style crowdsourcing service targeted towards agile startups with a rating system that startups can trust, and a high quality community of available freelance hackers.

Am I asking for a lot? Maybe. But wouldn’t it be useful?

HD over 3D

This past Wednesday I had the experience of being invited to attend the Rangers 3D viewing party at the theatre at Madison Square Garden. The Rangers vs Islanders game was the first sporting event being broadcast in 3D, and since no one actually owns a 3D television yet, the viewing party was pretty much the only way to take in the spectacle. Glasses were passed out to the 2000 people in the crowd, Rangers legends were on hand to host the event, NYC celebrities, the owners of MSG, cablevision, NYC media outlets, and the NHL commissioner and executives were all there to take in this potentially game changing event. And although the media would portray the 3D broadcast as a large success, I am less than convinced that 3D is the way of the future for the television industry.

Before talking about the market though, let me recap my experience. It was subpar. There were of course some very cool “a-ha” moments, where the broadcast would shift down to the ice level camera and a player would be skating directly out of the screen and into you as he dug a puck out of the corner boards. But for the most part it actually made the game more difficult to watch. I’m a huge hockey fan, and anyone who watched the olympics this year knows that HD-TV hockey is a thing of beauty. Gone are the days of the casual viewer not being able to track the puck in standard definition, and Fox feeling compelled to highlight the puck with a red tail on every shot. Unfortunately, the 3D broadcast made me feel like I was back in the standard def days again. Maybe it was just because of the awkward glasses not being positioned correctly on my face, me not being centered with the viewing screen, or the half-headache-half-nauseous feeling I’d get from the 3D, but it just wasn’t as crystal clear as it was sitting in front of an HD on my couch.

When HD was emerging in the late 90’s I don’t remember being aware enough of the market to make a prediction about it’s success (around age 15), but I would assume it was clearly agreed upon that HD was an improvement over SD. Anyone who compared the two side by side could tell which one looked better. Add to that the fact that the FCC was in the process of mandating television upgrades to digital enabled, and since people were buying new televisions anyway they would go with HD as soon as the costs came down. It seemed clear that HD would be prevalent in the near future.

Now compare that with the forces driving 3D television adoption. The experience right now doesn’t seem like an improvement to me in the case of hockey broadcasts. Maybe the NFL or NBA could benefit from it, but I can’t imagine there’s a huge value add to watching a drama or sitcom in 3D either. The equipment is expensive ($2500 television, $200 glasses). There’s a need to wear uncomfortable and awkward glasses. The standards in the industry are not clearly defined which is a problem for production and broadcast companies. And is there really demand for this? Does anybody want this?

ESPN will launch a 3D channel later this year, and it will be interesting to see if people purchase a 3D ready setup just to take this in. I’d rather save my money, and enjoy the better, easier, more relaxing experience that we currently have with HD television.

One interesting area to watch will be glasses-free 3D which a number of companies are already working on. At my old startup workspace, Soho Haven, there was a company called 3D impact media which produced these. When I would walk by their demo I’d often be shocked at their content jumping out at me. I’d like to think that this tech will eventually get as cheap and effective as the glasses required version, and when it does I’d be loathe to wear the glasses again. It seems like buying a glasses required setup now would be akin to buying a remote control connected to a television by a wire shortly before the wireless remote would be released. Hold off, and make your decision after the market plays out a bit.

* Setting iCal reminder for 10 years to look back at this post and find out how right or horribly wrong I was about mass 3D adoption

Glad to be part of JumpPost

I’ve made passing reference to a startup called JumpPost on this site, I’ve posted my status as JumpPost co-founder to the internets, and I’ve been shamelessly plugging away at everyone I know to give JumpPost a try for the past few weeks. I figure it’s about high-time to explain what exactly JumpPost is.

Renting an apartment in New York City is hard. JumpPost makes it easier by allowing you to browse, view, and apply for apartments that have never been accessible in the market before – apartments that will be coming up for rent months in advance.

Not only that, but if you’re planning to move out of an NYC apartment that you’re renting, you can make $500+ through JumpPost simply by listing it on the site. If someone wants to rent it, you earn money.

See the full gallery on Posterous

The NYC apartment hunt has always been an inefficiency that has affected me directly. It’s wrought with expensive fees, lying brokers, craigslist bait-and-switch offers, and the necessity to collateralize your first born child to prove your worthiness to rent. It’s always been a problem I’ve wanted to help solve, and that’s why a couple months ago I jumped at the chance to join Jordan Cooper as co-founder at JumpPost.

If I were from Boston I’d probably describe Jordan as “wicked-smart”, or if I were from Northern California I’d probably describe him as “hella-smart”, but since I’m from New York I’ll just tell it like it is: the man’s got vision, creativity, intellectual prowess, and he’s unwilling to see this thing fail. All qualities I was looking for in a co-founder. I’m super pumped to be working with him on JumpPost, which he had been plugging away at for a few months before I hopped on board.

There’ll likely be much more to come, re: JumpPost, on this site in the coming months, but for now if you’d like to learn more check out the site, or drop me an email at petkanics@gmail.com. As you’d expect, we’ve released early and are iterating quickly, so what you see now might not be what you see tomorrow or next week. If you know people living in NYC apartments you can even invite them to post the apartment on the site through our invite tool, and you’ll earn $100 if their apartment rents.

My thoughts on Rework by 37Signals

Sometimes just being reminded about what you already know is the best advice you can receive.

For the first time in two years of working on startups I took over a full week off this past week as I got married and went away on my honeymoon. While I wasn't doing any coding or checking in very often on startup life, I couldn't pull myself away completely, and I decided to take in 37Signals' new book, Rework, as a little light beach reading. I always recommend taking vacation and time off every once in awhile to help regather your focus and motivation for the grind that is startup life, and it turns out that Rework was a great companion read in support of that goal.

I really enjoyed reading Rework despite learning very little "new" information from it. Generally I read books to learn something completely new that I wasn't familiar with before. Rework is a bunch of simplified and restated agile startup lore that's prevalent on VC and entrepreneur blogs, hacker news, and greater startup-related internet. But it was the simplicity, verbalization, and centralization of all the restatement that really made it great. I have yet to read a business book that felt like it was reminding me of everything that I knew deep down and truly believed in.

Rework starts off a little bit broad, which is probably a good thing to attract any non-startup-world based reader. However it quickly gets down to the meat and provides nearly 100 1-2 page essays which really hammer home valuable lessons on specific topics. I particularly agreed with the chapters on Progress, Productivity, and Hiring. While I'm a vocal advocator for launching early, iterating quickly, and staying cheap and lean for as long as possible, it's easy to stray from some of these ideas along the long road of building a startup. I'll go back to Rework every once in awhile to set me straight when I feel myself veering off the path.

The book doesn't take that long to read, and the 1-2 page essay format makes for plenty of breaking points, so I strongly recommend throwing it on your e-reader or into your backpack and taking in an essay or two whenever you have a few moments. I emerged from each chapter feeling energized and eager to get back to work on my startup and my product – to get back to doing things the right way.

Thank You Heroku, or “How To Eliminate Sysadminning”

I need to take a couple minutes here to do something I've been meaning to for along time: Thank Heroku for being so baller.

For those of you not in the know, Heroku is an all-in-one Ruby platform built on top of Amazon web services. If you're a Ruby developer, and you are creating a web application, I highly recommend checking it out.

I've been using Heroku on two applications, including JumpPost, which officially launched today via a nice writeup on the Thrillist NYC site and newsletter. I'd like to share a couple reasons why I love the Heroku platform and would advise any agile startup to consider using it to get their product launched quickly.

Heroku is fast

The same could be said for any well configured EC2 instance, but don't underestimate the words well configured. The smart folks at Heroku have fine tuned every layer of the stack from using the fastest web servers (nginx), caches (Varnish, Memcache), and load balancing strategies.

Heroku is scalable

At the core of Heroku's architecture is a pre-compiled version of your application called a "slug" which is ready to be deployed in seconds to as many instances as you desire. Expecting a big press hit, or noticing your request queue filling up, just type a simple command and add more resources in seconds. Your users won't even know.

Heroku is easy

To deploy you literally type one command at the command line. They provide add-ons for caching, email, DNS, performance monitoring, custom domains, etc…many of them free.

Heroku provides killer support

Not only does the staff respond to tickets and support requests within minutes, but they go overboard to support the latest and greatest Ruby features. They're very active on the newsgroup, and they even provide sample code for how to best utilize their architecture.

Heroku is cost-effective

People may argue me on this one, because at face value the cost is actually rather expensive (think 2x the regular price of AWS). But these people aren't taking into account the cost of their own time when it comes to sysadminning, troubleshooting, not the mention the cost of downtime. Heroku never goes down, and it eliminates the need to pay a sysadmin (or the time value of sysadminning yourself).

Heroku is beautiful

Don't believe me? Check out their pricing page (yes they know their demographic are samurai loving programmers). Navigating their site to manage add-ons, monitor performance, and scale up and down resources is a pleasure.

With all of the above, there are a couple downsides that people should be aware of. Proper SSL is expensive, and should your app face custom scaling needs or challenges then you are locked into their stack. Fortunately their stack is designed for large scale use. The Heroku folks are well aware of these concerns, and they're very open about what they're doing to improve the experience for all of their customers. For startups getting their product off the ground, the time savings early on far outweigh the cost of figuring out a custom solution later should your product achieve grand scale. In case you couldn't tell, I'm a big fan.

If you have any questions about the platform, don't hesitate to email me at petkanics@gmail.com.

Why I release early

Many people know that I'm a big fan of the "release early, release often" motto that still echoes from my days going through YC as an early developer with Frogmetrics. When I launched Snapm I tried to live by this mantra as I built and released v1 in a little under a month. That proved to be one of the most valuable decisions I made as it allowed me to get plenty of feedback and early user testing way before anyone normally would have seen the working site. In my latest project, JumpPost, I attempted to push the boundaries of an early release even farther by rolling back the curtain as soon as the product did one simple thing. (The JumpPost background and story to be written about in a future post). Why do I do this? A couple of reasons.

First of all, as it's been written about many times, there's no better substitute for customer research than real user feedback. I strongly believe that you don't know what your users want, and they don't even know what they want, until they're actively using your product. I've seen countless occasions where users demand one feature or component of a product (IT MUST WORK ON AN AIRPLANE!) only to realize that they have no use for it after it's been built.

More importantly however, there's no better motivation to constantly improve your product, than to have a less than complete product out in the world. There's a saying among agile developers that, "If you're not embarrassed of your product, then you haven't released early enough." I'd modify that a little bit to say, "If you don't feel the obligation to your customers to be constantly improving your product, then you haven't released early enough." It's not quite as powerful as using the word "embarrassed", but I purposefully don't use that word because the last thing I am is embarrassed about releasing early. In fact I would say that I'm the opposite of embarrassed. I'm proud to have released early. I can't wait to push new changes and updates to the site multiple times per day. I can't wait to watch our users marvel at how they request a feature and it's implemented and released within days or hours. That's the stuff that makes you want to work.

It's easy to delay launching. There's always another "must have" feature to be built before you feel that you're ready. But it's hard to put yourself out there. I strongly recommend giving it a shot on your next project.

If you live in NYC and happen to be moving out of your apartment in the next 6 months, check out JumpPost.com and list your apartment. You'll make $500 if it rents, and you'll hardly have to do any work.

The DOB

Insights by Doug Petkanics

Monthly Archives: March 2010