What Programming Language Should I Use to Build a Startup?

Often entrepreneurs ask me 'What technology should I build my startup on?' There is no right or wrong answer to this question. It's a decision every company makes for itself, depending on what it's trying to build and the skills of its cofounders. Nonetheless, there are a few rules that one should adhere to. We discuss them in this blog post.

Incident Response Policy

What happens in your company when a production incident occurs? Usually in a typical startup, you will see engineers running around frantically trying to resolve the problem. However, as soon as the incident is resolved, they forget about it and go back to their usual business. A good incident response policy can help bring order into chaos. We provide a sample template in this blog post.

Why Software Deadlines Never Make Sense

We discuss why software deadlines usually don't make sense.

Analyzing Front-End Performance With Just a Browser

We discuss a number of freely available online tools which can be used to analyze bottlenecks in your website.

Why Smaller Businesses Can't Ignore Security and How They Can Achieve It On a Budget

In this article, we show that security is both important and achievable for smaller companies without breaking a bank.

Thursday, June 27, 2013

Good Advice

"Most days you have 100 things on your to-do list. Most people, when faced with such a list, will find the 97 that are obvious and easy and knock them off before worrying about the 3 big hairy things on the list. Don't do that. The 97 aren't worth your time, it's the 3 big hairy things that matter." (Posted at

Saturday, June 22, 2013

Design for Failure

RightScale gave a good tutorial on how to architect applications for Amazon EC2 cloud to be highly available. Here is the link:

Friday, June 14, 2013

No Meeting Zone

Developers need to have long blocks of time, uninterrupted by meetings, to get work done.
One simple trick to enforce is : one day a week, block calendar time with a "NO MEETING ZONE". Train people in departments outside of Tech that this time is sacred and all meeting requests shall be ignored.

Tuesday, June 11, 2013

Pragmatic Programming Techniques: Scalable System Design Patterns

Pragmatic Programming Techniques: Scalable System Design Patterns: Looking back after 2.5 years since my previous post on scalable system design techniques , I've observed an emergence of a set of common...

Saturday, June 1, 2013

Tips for a Successful Hackathon

I had a great time visiting the Cinchcast engineering team in Buenos Aires, Argentina a couple of weeks ago. While I was there, we spent a day on a hackathon building some long awaited features for Blogtalkradio.


This prompted me to think - what are some tips for hosting a successful hackathon in a company.


 1. Set expectations. 

It's hard to build clever and innovative code within 24 hours. It's even harder to make that piece of code ready for Production within such a short timeframe. It's a job of a CTO (or a hackathon organizer) to manage expectations of the business stakeholders about the results. Explain that the hackathon will improve the team morale, teamwork, and may result in key business features. But be upfront that it's likely the code will need more polishing and prioritization in the backlog before it's released.

2. Choose a good working space.

A good working space for a hackathon is key (and plenty of caffeine). I recommend getting out of the office so the team feels a different vibe. For example, in NYC Cinchcast engineering team often goes to hack in the lobby of the Ace hotel.    In Buenos Aires, we rented for a day a conference room in Urban Station in historic neighborhood of San Telmo

Urban Station San Telmo, coworking space in Buenos Aires, Argentina

3. Ignore complaints. 

The engineers usually work hard enough during the week so I don't believe that they should sacrifice their weekend for a hackathon. As a result, no matter which day you pick (during the week), it will never be ideal. There'll be looming deadlines and projects that people need to deliver.   Most people will love working on something new, but a minority few will always complain.   Ignore the complaints!  It's for the greater good. Even though hackathons may disrupt the sprint process, people will collaborate with each other, innovate, and have fun.

4. Split into teams of people who usually don't work together.

It's best to break a group into small teams of 2-3 people each. Not everybody in the team has to be an engineer : QA, Product, or Designers should feel welcome to join in and provide valuable advice. Encourage pair programming between engineers instead of each person in a team working separately.

5. Steer the team to work on useful (fun) projects.

The projects need to be ambitious, interesting, and fun  BUT they should not be entirely useless for the business.  What I like to do is solicit opinion of everybody in a company, asking them for cool ideas for a hackathon.  But in the end, the engineers decide which projects they want to work on themselves.  As the groups debate, ask them "How will this be useful for the business?"  "How will this project be useful for you?"   Steer the groups, but let them make the final choices.

6. Have fun (and take breaks)!

Don't just code - take a lunch break together, talk about life and technology.  Everybody will be productive this way.

7. Do demos and review the code at the end.

Finally, at the end - make sure everybody gets to look at the cool projects that people built.


Going back to the Cinchcast hackathon, we had a lot of fun. We split into 4 teams and worked straight for 12 hours.  

We worked on various features ranging from better Facebook integration for Blogtalkradio homepage to building a mobile listener app prototype using a new Xamarin framework   This framework allows to create cross-platform apps for IOS and Android in .NET.

We have also experimented with live video feeds of the presenter using WebRTC technology, but found the technology to be too nascent.


 Overall, this was a lot of fun!