Supersize Your Startup Dev Productivity

AttributionNoncommercialShare Alike Some rights reserved by Dav

Since I wrote the interview with Farhan of Xtreme Labs on Pair Programming, I have exchanged a number of emails on pair programming & developer productivity with some of Canada’s best developers. Most of them are pure gold that I am posting raw and unedited.


“The main thing we like to stress on development is Test Driven development. We just find that it both ensures all the code is well tested, but also guides the architecture in a way that really improves maintainability. We use pairing in our interview process and also like to pair for the first couple of weeks to get developers up to speed, but after that we tend to split up work for the day and then attack separately.” – Jesse Miller, CEO of


“Whether to use pair programming or alone model really depends on the team personality and the kind of culture the leaders want to shape up. Some people do work better alone, and some prefer more teamwork.

Personally, I usually value teamwork more than individual results. At the end of the day, individual work will have to be integrated to form the end product, which is what really matters. There are too many examples where people think they got great ideas, but end up in epic failure during implementation. It is a result of not doing deep enough design validation. Coding alone is definitely more effective when you got the design details flushed out. Personally, when I am coding alone, I still ask for 2nd or 3rd opinions on a day to day basis. It forces me to think through the design again and again, which helps to refine my idea further. It is all about attitude. Never believe that you got it right until see the end product.

Another interesting thing is “pair troubleshooting” is more effective. When you’re trying to debug in an extremely stressed environment, it is always good to have some mental support and another pair of eyes.” – John Yuen, heads up dev for Fixmo


“I think that pair programming does actually increase productivity, in most cases, and there are two reasons for this:

1. It keeps programmers from doing other things:private email, browsing, day dreaming, etc. I doubt that the average programmer actually spends even 50% of their time doing their job. If you can hire two developers, and get the work of one full programmer out of them, then I think, in a lot of cases, that would be an improvement. However, you could get almost the same result by pairing each
programmer with their own full-time low-cost supervisor who sits beside them to make sure that they’re actually working. This would be a lot cheaper and almost as productive, but the developers would find it insulting. This isn’t always the case of course; there are certainly many self-motivated, disciplined, highly-focused and productive developers who don’t need supervision.

2. Studies have shown that programmer productivity is limited, not by the time it takes developers to write code, but by the time it takes them to detect and correct errors. The limiting metric isn’t lines-of-code-per-hour, but rather, errors-debugged-per-hour. This is why Java is more productive than C++, despite the two languages being of similar expressive levels, Java’s runtime exceptions make it quicker to detect and recover from many times of errors, and garbage collection completely eliminates many other types. This is where pair-programming comes into play, if someone looking over your shoulder can spot an error as soon as it’s created, then that can lead to a lot of time savings. Maybe it would have only taken you two minutes longer to detect and fix a particular bug, but then gain, maybe it would have taken a week. Your partner wouldn’t need to early-detect very many problems in order to justify the overhead.

Maybe one developer sitting in a control booth, like a security guard, monitoring the work of half-a-dozen developers all at once, would be a good compromise between pair and pair-less programming.

Yes, it’s true that ACM programming contests are performed on only one computer, but you rarely have more than one person working on the same problem. While one is typing in and debugging their solution, the other programmers are working with pencil and paper solving their own problems (with occasional help from their team mates as required).

People are more important than any process or any tool. The best process is to hire the best people and a better developer is the best tool.

I half agree with what the original article says about hero developers. They say that you don’t need them, and that you’re better off with the a consistently productive 9-to-5’er. I think they’re
confusing heroes with heroics. I think that you do need heroes, but you don’t need the heroics of pulling all-nighters. Instead, you need the heroics of consistently creative and proactive problem solving which keeps you efficient, effective, and ahead of the game, day in, and day out. Effort should not be confused with results. I think they have the wrong definition of heroics, which leads to the wrong definition for heroes.” – Kevin Greer, Framework Lead at Redknee.


Point #2 from Kevin Greer’s comments is widely unappreciated. Most people judge productivity by features and the “to do” list – when in reality it is not the to do list of features that usually makes projects late, it is the killer game of bug squashing, especially as you get to the stressful end of project delivery. Processes that reduce the upfront bug rate or increase the bug solving rate, even at the expense of adding features pay off quickly. This is were pair programming, test driven development, code reviews, architecture chats, etc all come into play. And why “pair troubleshooting” or other tools to debug problems fast are important. And also, use the damn debugger, it is there to make solving bugs faster.

I’d love to hear from more of the programming community in the comments. Tell us how you supersize your development productivity.

Hustle & Flow

Once upon a time in my startup life, we stumbled across the deal of a lifetime. A large company was spinning off a subsidiary, and they were paying someone a few million bucks to take it off their hands.

Most folks looked at the numbers and said “no thanks” – $7mm in revenue and spending about $20mm… yuck. But these guys were running the exact same business as us, similar subscriber counts and all, and we knew they could be run spending $3-$5mm per annum (which is what we were spending). For instance their CEO was getting $4mm/annum and ours was making $1/annum (perfect example of why big companies can be bad at launching new products). So we put in a bid for -$2mm (yes thats a minus in front). I.e. pay us $2mm to take your company, and have it generate $2-$4mm a year in cash for us. Booya. You could imagine how excited we were. We basically re-enacted this Monty Pyton scene every day in the office for 2 weeks (word of caution – this is 10 minute video and there’s a part 2):

Yaaaaar, corporate raiders be we.

Until, sadly, of course, somebody outbid our -$2mm offer. Damn. I suppose -2mm isn’t that hard to outbid.

I’m telling this story to give another “meme” to startupdom. Lean product development, social marketing, customer development, iterations, pivots, etc – these are the more popular memes of today. Well there’s another one thats not mentioned enough – Hustle and Flow – doing deals, business development, partnerships, strategics, m&a, etc. There are many big famous startups who had deals with a big elephant: Google powering Yahoo, Amazon powering Target, the Microsoft/Apple/IBM/Xerox tangle, RIM’s pager deal with Ericsson. Its a crucial part of growing your startup, you gotta be able to do deals.

One of the current killer “deal-oriented” startups in Toronto right now is Kobo Books (@mserbinis). Kobo got frickin’ Li Ka Shing to back them, the guy is a business legend! Why waste time with tiny business punks like Paul Graham and Dave McClure (I joke) when you can have a business God invest in you. Plus Kobo has done huge, killer deals from top to bottom in every category of their business – checkout their partner list in here. That my friends is big pimpin’ Canadian startup style.

Here’s another one, check out the list of deals Fixmo (@ricksegal, @shyamsheth) has done. They acquired a company (Conceivium) as a year and a half old startup! How many of you entrepreneurs in your first year or so wake up and say “lets buy a company”. On top of that, as an unknown one year old startup they walked into the Department of Defense in the US and nailed a massive deal. That is pure brass-balled, biz dev game.

Would love to hear some other great Canadian business hustler success stories from folks (or near misses, or disasters), or give us your favourite links/resources for networking, bd, m&a, hustling, pimping, whatever. We’ll be following up with some resources and tips to help your biz dev game.