Category Archives: Technology

Music Hack Day – Aug 10-11

CC-BY-NC-ND  Some rights reserved by TonyFelgueiras
AttributionNoncommercialNo Derivative Works Some rights reserved by TonyFelgueiras

“Music is the soundtrack of our lives.” – Dick Clark

There are an amazing set of Toronto based music startups emerging.

It should come as no surprise that with a burgeoning community there are events. Paul Osman (LinkedIn) who is now part of the team at SoundCloud and Rdio, The Echo Nest and Unspace are hosting:

musichackday

  • To fast prototype and create brand new music apps (web, mobile or physical) in just 24hrs.
  • To bring together the music industry and the developer community.
  • To highlight and showcase the platforms and API’s of companies working in and around music tech.
  • To foster cross-platform and cross-device innovation.

Looks like a great event for local startups and developers to get access to APIs and hopefully distribution.

Music Hack Day Toronto will be held on August 10th-11th, 2013 at the The Glass Factory, 99 Sudbury St.

If you are interested in participating in the fast prototyping and creation of brand new and innovative music apps, be sure to register (tickets are free) for Music Hack Day Toronto today.

The Pending Talent Wars

 

CC-BY-NC-ND-20 Some rights reserved by Today is a good day
AttributionNoncommercialNo Derivative Works Some rights reserved by Today is a good day

Did you know that accelerators are heading for a shake out? We’ve talked a lot incubators, accelerators and cyclotrons. And the proliferation of the accelerator model is generally positive, it started me thinking about a possibility for slightly different model. One that Kevin Swan posted an insightful comment on the talent shortage for Canadian startups. I don’t think I’m the first to propose this, but it starts to make sense. Incubators/accelerators don’t need to only hasten the formation, creation and ideation of companies. They are fertile grounds to accelerate people. And it’s not just incubators and accelerators, companies participate in HackDays to find talent.

Need proof?

Vuru acquired by Wave Accounting

Vuru founders Cameron Howieson and Yoseph West reached out to the Wave Accounting team for advice on building a free, web-based financial services tool. Over time, the two companies traded notes as Wave took on a an informal advisory role, and that led to a sense that Vuru’s talent and direction were something that would be well suited to the Wave Accounting mission. — Darrell Ethrington, Aug 21, 2012 in BetaKit

Vuru was a 2 cofounder team in the FounderFuel (full disclosure: I am mentor in FounderFuel and I now employed by Wave Accounting investor OMERS Ventures). They were building a “investment tracking tools aimed at managing personal finance, which is not something Wave currently offer[ed]“. It was a great fit, a team that had the entrepreneurial culture to make a difference at Wave and a product that filled a known product roadmap gap.

Algo Anyhere acquired by 500px

Ok, before Zach Aysan slaps me for being totally incorrect. AlgoAnywhere was not in an incubator or accelerator program. But they had raised a seed round and were building very interesting technology.

The 500px founders met Algo Anywhere at their Pixel Hack Day last year, and were impressed by what the team brought to the table. Algo Anywhere’s tech was originally intended to be sold on an SaaS basis, providing companies with the data crunching power of sophisticated recommendation algorithms, without the need for those to be developed in-house or hosted on a company’s own servers – Darrell Ethrington, July 9, 2012 in BetaKit

The interesting point here isn’t about incubators or accelerators. It’s about founders of early-stage companies looking for relationships and gaps in the market left by other players.

Pulpfingers acquired by 500px

It seems that 500px has been strategically acquiring companies. It looks like both Pulpfingers and Algo Anywhere were part of the PixelHackDay (see photo from TechCrunch). Which gives 500px access to see designers, developers working in their domain space. It’s a great way to round out the product roadmap, Pulpfingers was a iOS discovery application. And they aren’t alone. Hootsuite acquired Seesmic and Swift.

Built to Last versus Built to Flip

I’m not arguing that founders should be looking to build companies to flip. There is lots of conversation about building lasting value. I’m arguing that companies that have raised capital to scale are looking for alternative methods to acquire talent. Get access to the API, build a meaningful service, acquire shared customers and go forward, it’s Biz Dev 2.0 (as Caterina described back in 2006). What’s new to the game for Canada (well Canadian startups) is that for the first time since RIM we are starting to have web startups that are reaching scale and are able to acquire talent, teams and companies. The goal isn’t to look for a acqui-hire or a manquisition, but to look at where working with an existing company or API gives you immediate access to distribution or monetization that you might have to work harder to build on your own.

I’m betting that companies like Wave Accounting, 500px, Influitive, Hootsuite, Shopify,Freshbooks, Top Hat Monocle, WattpadUpverter, Chango, FixmoDesire2Learn, Lightspeed are all actively looking for teams that are building on their APIs or filling product gaps (it becomes a buy versus build decision).

If I was a developer or looking to get into an incubator program, I’d start looking at the hackathons and APIs that are aligned with my vision where I could accelerate customer adoption.

Events

APIs and Developer Starting Points

Find an API (be it local or otherwise) that aligns with your vertical, figure out if you can solve one of your immediate challenges (like distribution and customer acquisition). Maybe strike up a conversation with the product teams at shop. But build something that delights customers and users! Go! Now!

Who has something built on one of the above APIs?

Is Code Written To Be Read?

The other day I attended a tech talk hosted by Facebook. Their internal platform team was talking about how they manage the Facebook framework and code base.

The presentation was titled “Code Is Written To Be Read”.

Immediately my gag reflex kicked in. Code is written to be read??? Really??? I literally can’t remember the last time I sat there and thought “hmmm, how readable is this code, I wonder if so and so will be able to understand this”. Having said that, I think I was the only person from a startup in attendance, most were from Google, Zynga, and other larger tech firms. So perhaps I was the wrong audience for this topic.

Whatever their problem is, it is not mine. In my world I have one reason to write code – TO SHIP.

“Code is Written for Users to Use It” (i.e. just ship or shipping is a feature) – that is the startup equivalent mission statement.

And this is where all the “maintainability” coding trolls come in and leave comments like “yeah, but it’ll be huge advantage if we can iterate quickly and get a v2 out and so on and so forth, thus we need code thats easy to maintain”.

No.

Here’s the reality – your product is likely going to fail, so if you wasted time and money making fancy abstractions, doing code golf, and focusing on elite coding craftsmanship… you blew it. You failed. You should have finished it 2-4 weeks earlier instead.

You have to EARN maintenance as a problem. You have to EARN v2. You have to EARN the right to practice expert craftsmanship. If you get there, if you really get to the point where maintaining your code base is a problem for you where many other developers are reading your code… congrats! You’ve succeeded. Go nuts, rewrite everything. You deserve it!! Forget every word I am writing, and go attend the Facebook tech talk and take diligent notes.

But for most of us, we are not going to earn that right. We are going to fail or pivot or leave or get acqui-hired or whatever. That code is going to get thrown in the trash never to be touched again. So how’s that clever FactoryOfTaskFactories abstraction feel now?

And that’s why you probably don’t want to hire Facebook or Google engineers for your startup. And more so, if you are a new grad engineer who aspires to be a startup founder one day, that’s why you don’t want to join Facebook or Google.

Look, it’s not that there is something wrong with those developers. I’m sure working at Facebook or Google is fantastic. It is the closest thing to a tenured prof position you can get in this field. The problem is that they operate under significantly different operating conditions than you do (unlimited money, unlimited time, lots of technical resources, working across massive teams, etc + MASSIVE scale problems, huge performance requirements,petabytes of data, etc). They learn a very different craft than you do.

Your craft, the startup developer craft, is simple – “get things done”. The other parts of the craft, you have to earn.

(caveat – if you are building a startup focused on platform or tools being used by other developers, your craftsmanship should be excellent)
(disclaimer – I have nothing against facebook or google, they are full of friends of mine and other wonderful and smart ppl)