In February this year, Fred Wilson wrote a great piece about the need for mobile app “glue” (my words). Here is the exact phrasing:
“When I was at the music hackday a few weekends ago, I noticed that it was easy to build something interesting by simply snapping together a few web apps and then building some light glue between them. I suspect it will be even easier to do that on mobile and the era of “meta apps” that deliver functionality across multiple apps is upon us. And I think that has the potential to create some new startup opportunities.”
Kik has provided a device resident SDK so that application developers can build sharing into their apps. It is such a powerful idea – sharing done on the device. Until now, if a mobile app developer wanted to do sharing, that capability had to be basically hosted “in the cloud”. Think about picplz & instagram. They have had to use Facebook, Twitter and other “web” platforms, and connect to them via some cloud servers. Well, with Kik’s SDK, mobile apps can now share “natively” on their mobile platform. No more cloud – huzzah!
‘Everything is better with friends’ By giving your users the ability to share with each other in real time, your app will be that much more fun and compelling (see the Sketchee story below). Sharing can also give a big boost in adoption – when a user who doesn’t have your app receives a Kik content message from it, Kik offers to take them directly to your download page where they can install it. All of a sudden you aren’t asking your users to share your app with their friends, but to share content from your app with their friends – content that requires them to get your app to view and interact with it. It’s the difference between inviting someone to join a social network vs. tagging a photo of them that requires them to join the social network to view it. And best of all, it will only take you 10 minutes to add this kind of functionality to your app.
On top of all that, Kik is giving away $5000 to each of the top three applications built on their SDK. Finish your app by August 8th and you can get in on that.
I am always curious at what startups are using for the technology under the hood. It helps define the technologies that frontend and backend developers looking for jobs might start using. It helps understand what skills are being developed in the ecosystem and where competition or coopetition for talent may exist. And I am always curious at the emerging trends of technology adoption by local firms.
The online advertising landscape is changing rapidly, Chango is taking advantage of Real-Time Bidding to allow marketers to buy ads on the web in real-time. It means big data where time is critical because small fluctuations in price or users can have big impact on the overall effectiveness or cost. The best analogy is a stock market, where instead of stocks, marketers can buy billions of ads each day based on how they think that websites ad slots will perform for them. The cool part about RTB is that you can combine data to put the right ad in front of the right user. This requires huge data processing skills and Chango processes information on about 60,000 ads a second.
What does Chango do?
We are an ad-buying platform that is built for online marketers looking to find new customers using display (banner ads). Our main goal is to eliminate wasted marketing dollars through smarter targeting. Specifically we show ads to people based on what they’ve searched for in the past – a technique we are pioneering called “Search Retargeting“.
Unlike traditional ad networks we exclusively buy ads using real-time bidding, a new technology that is rapidly changing the Display advertising industry and allowing marketers to layer data on top of their media buys.
Chango is unique in that it has access to billions of search terms, billions of incoming ad impressions, and has devised machine learning techniques for combining data from different sources to deliver more efficient and better-targeted campaigns for our advertisers.
What does your product architecture look like?
Software development that deals with “Big Data” typically has two types of challenges: big volume, or low latency. Chango has to deal with both of these issues simultaneously.
We receive over 90,000 requests per second (and growing monthly) from our ad exchange and data partners at peak times of the day. To make matters more interesting, we have approximately 80ms to respond to any incoming bid requests. Unfortunately 30-50ms of this limit is used up because of unavoidable network latency, this leaves us only 30ms to process each bid request. As a result, we have to constantly optimize our bidder subsystem around this challenge.
What are some of the tools and technologies you use?
Open Source is at the heart of our technology stack. Python is the common thread that binds all of our subsystems. Our entire infrastructure is written in Python. We use a (modified version of) the Tornado Web Server for our realtime servers, and Django for the front-end.
When dealing with super fast response times it’s critical to have a super-fast datastore at your disposal. That’s why we use a NoSQL database technology based on the proven memcached server.
The unsung open source hero of our infrastructure is HAProxy. HAProxy handles our load-balancing across the board. We use the “keepalived” feature of Linux to keep these servers in high-availability mode.
As far as our architecture is concerned we try to not have any major dependencies on any specific features of the third-party systems we choose. They just happen to work well for our current environment.
How did you get here?
Scalability is as much an art as it’s a science, but most importantly, it’s about keeping things simple. It took years of hard work, and careful tuning and measurement to arrive at where we are.
Originally we used Java for all server-side development and Ruby on Rails for front end development. The thinking was that we needed a rock-solid language for server architecture and a rapid development environment for front-end work. This concept served us well for a little while; however, in early 2010 we realized that Java was drastically slowing down our ability to iterate quickly and effectively. A single feature was taking days to build, test and deploy.
We bit the bullet and rebuilt the platform entirely in Python and it was probably the best decision we ever made. Not only do we have a consistent language across front end and server side development but it has enabled us to rapidly add features or test new ideas. We are fortunate to have access to the fantastic ecosystem created by the Python community.
Where do you host?
Our first approach back in 2009 was to leverage Amazon Web Services EC2 as a scaleable and cheap way to prototype the platform. That served us well for a while; however, the shared virtual environment meant that we had wildly variable server resources.
We shifted to Hosting.com knowing that we ultimately needed our own equipment and if we wanted a VM environment we would need to set one up ourselves. While Hosting.com provided good support at the time we wanted the rapid provisioning we were used to at EC2 with the power of dedicated hosting.
Ultimately we chose SoftLayer as our hosting provider of choice. SoftLayer offers a VM environment in addition with their “express” service that allows us to get 10s of new servers provisioned in about 3-4 hours! They have been extremely good about allowing us to occasionally provision a whole new parallel cluster as we do capacity planning.
How do you monitor your systems?
Monitoring is done through a combination of Nagios, PagerDuty, and Circonus among others. We have also built a real-time data visualization system that let’s us monitor both infrastructure, and campaign performance. We use this dashboard as our own NOC system hooked up to a TV that is mounted right in the engineering area!
What are your biggest development challenges?
We’ve got two distinct challenges. Our real-time, data processing, and systems engineering teams deal with problems of scalability and big data. As our business continues to grow, we need to re-examine our infrastructure and design choices. We have a very healthy culture of team collaboration, code-review, and refactoring.
Our Dashboard team has a different set of challenges. Our self-serve ad platform is very much like Adwords in that marketers can put down a credit card and launch a campaign themselves. We need to make this an extremely user-friendly system, while keeping it powerful enough to enable people to perform sophisticated reporting and campaign optimization.
How do you win?
The Chango business is all about putting the right ad in front of the right user at the right time. We made an early decision that data you know about a user (ie. search data) is only effective if it is combined with a proprietary bidding engine that can make decisions in real time.
Almost every DSP, data provider or ad network out there today does this by storing information about users in a client-browser “cookie”. They call this a user segment. The problem with user segments is that they are pre-computed and stored within the users browser. If you decide half way through your campaign that you need to adjust your audience (due to lack of performance) there is no way to do so since the information is hard coded in the users browser. The only option is to continue serving ads to this under-performing group of users and wait for that cookie to expire (typically 30 days).
At Chango we’ve decided to make everything real-time, including our decision about who to bid on, and how much to bid. Nothing about the user is pre-computed. So the Chango ‘cookie’ contains nothing more than a unique identifier that anonymously points to all the raw data we know about that person in our database.
Chango is hiring!
Python Developers! There are multiple open positions in Toronto, New York & San Francisco. But if I could have anything it would be talented developers that either know python or want to learn Python.
Interested in being profiled in our Under the Hood series, we are actively looking for Canadian startups building “interesting” technologies and solving “interesting” problems. Contact me by completing your initial Under the Hood submission.
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 attachments.me
———————————————————————————————
“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.
Congratulations Christopher Golda (@golda) and Michael Montano (@michaelmontano) on Twitter acquiring BackType. We’ve written about BackType since their acceptance in YCombinator (fortunate that we didn’t give iPartee their previous startup too much attention). This is another amazing acquisition of Canadian startups by a Silicon Valley company (make it 16 acquisitions since Jan 2011 see TechVibes). I think Dan was right, this could be a $1B year for Canadian startup acquisitions.
The BackType team had already relocated from Toronto to San Francisco. And it looks like the relocation to the Twitter offices should be much easier:
Our team’s relocating to the Twitter office. We’re very excited to not only join an amazing company that’s changing the world, but to continue building products in pursuit of our shared vision with Twitter.
So I just finished a big tour de Southeast Asia. There is really only one story going on over there – Mobile. Check out this research from BCG (BRICI = Brazil, Russia, India, China, Indonesia):
1.2B new internet users coming from BRICI countries by 2015
Mostly coming from mobile, much of that will be advanced feature phones (not smart phones)
Social in Indonesia & Brazil, Email in India, IM in China (QQ FTW!!!)
That will only result in 20% internet penetration in those countries (i.e. lots more to come!)
All of this is happening here and now. There are huge opportunities for any mobile startups to break into these countries. Let me give you a taste of Indonesia.
Two years ago Nokia had 60% of the phone market. A retailer called Nexian had just started up with the idea of importing and reselling Chinese manufactured phones and branding them as Nexian phones.
Fast forward to today. Nokia is down to 30% of the market!!! Nexian is one of the dominant retailers, they just sold to the Spice Mobile family (large conglomerate in India exploding across Asia, Middle East and Africa). You can get a stylish QWERTY phone with a big display with pre-loaded apps including email, Opera Mini, Facebook, Twitter, Mig33, Nimbuzz IM, private messenger, widgets, news reader, etc, all for < $40 (in some cases closer to $20). You can also get a Nexian Android phone for $150-$200.
[caption id="attachment_9327" align="alignleft" width="640" caption="This Bad Boy = $20"][/caption]
Everybody is ripping off Nexian’s go to market strategy. The telecos have launched new brands to sell these phones. The retailers have gone to China, sourced phones and are re-selling them. The Chinese manufacturers have opened up retail in Indonesia (Huaiwei has their own stores!). On top of that I counted at least 20 Nexian clones, small companies with the same strategy as Nexian.
Blueberry Probably Outsells BlackBerry 2:1 In Indonesia
Nexian has countered by offering apps & services on these $20-$40 phones. People don’t have data plans, so Nexian does micro-billing via the carriers. 10c/week for Facebook, 5c/day for IM, $3/month for chat as examples. It works, they make millions a month from it.
There are roughly 170M phone users in Indonesia.
For Canadian startups, this means that there has never been a better opportunity to build mobile apps and “go global”. Check out if your app has a competitor in markets like Indonesia. All these phones in Indonesia (and China and India) are on a single platform with a single OS -> MediaTek. Port your app to MediaTek and go get deals with any of the manufacturers, the Nexians and their clones, the operators, etc. You can either try and get a royalty up front with your app pre-installed on the phone, or you can work out a rev share agreement on the service, or whatever other monetization scheme you have in mind.
There are plenty of folks who can help you with local business development. For instance, if you are a mobile app startup and you think Indonesia looks hot, Andy Zain runs the Indonesian Mobile Monday and Founder’s Institute. He is incredibly well connected in the teleco scene and he has helped startups like mig33 and Payfone (you are also free to reach out to me for contacts and info as well). In every country there are guys or companies like him. A bit of research and networking and you can find them.
Next week I’ll have some more on the start-up scene in Singapore, including some info from the leading startup blog over there (sgentrepreneurs.com).
Nothing like the last minute planning around here. Ian Jeffrey (LinkedIn, @ianmtl) from FounderFuel is planning on being in Toronto today (June 27, 2011) and tomorrow (June 28, 2011). He is planning on meeting with startups and founders to share his experiences launching FounderFuel, the mentorship and incubation/acceleration plan for participating startups and to talk about tech startups generally. If you are interested in talking with one of the emerging technology company incubators/accelerators you should come and talk to Ian and learn about what is being offered in Montreal. There is a lot of choice in the marketplace for entrepreneurs, and the best way to see the differences are to connect with the people behind the scenes like Ian and the FounderFuel team. This is a great way to evaluate the program, get introduced to the people, and connect.
From the looks of Alexa Clark’s (@alexaclark) photo exposition at Camaraderie, it is a great space to host a startup. I know that Matt (@mattskilly) and Aron (@defrex) at Hipsell have their startup offices there. It is a great space for startups requiring a great work space, a central location, and the benefits of an enabled coworking culture.
I won’t comment on what exactly is happening at RIM, there are more than enough people doing that these days, but instead I think it is time for Canada to think about how to mitigate our losses here as the attrition continues. I am more interested in how we go in to damage mitigation mode. I think there is an obvious thesis developing for one or two new funds to camp out in Waterloo and focus on extracting the value locked up in RIM.
A gravedancer fund would focus specifically on leveraging the talent and IP as it spins out of RIM in Waterloo. It would hasten the gutting, no doubt, but somebody has to do it and it may as well be someone based in Waterloo.
So, who is going to raise the Gravedancer Fund and where do I sign? Waterloo is on it’s way to becoming the center of startup activity in Canada and the death spiral of RIM needs to be seen as an opportunity, not a threat.
Editors Note: This is a guest post by first-time entrepreneur Mike Potter (LinkedIn, @mike_j_potter) who previously was a Marketing Manager at Adobe, a project manager at Mozilla and an engineer at an Ottawa area startup. Mike has spent time running marketing programs for a large organization and has realized that power he held for many early-stage startups.
It has been 5 months since I left my job at Adobe and started my own company, Arkli. We are building software to help create and measure integrated marketing campaigns. If I’d known how little it takes to help a startup, I would have tried to do far more when I was Adobe. It has been the experience of starting my own business, and demonstrating customer traction to potential investors and potential customers that I’ve come to realize how important 1 or 2 early customers like Adobe can be for a startup.
Demonstrating customer traction even in small numbers (particularly for enterprise or B2B startups) is the thing that helps you get the next meeting, the next introduction or the conversation that can really help your startup. For example, we’ve been in business for less than 7 months and we have 2 customers. When I was at Adobe, I would have said only 2 customers – that’s all you have? We had tens of thousands of customers. It was unclear that 2 customers could matter on the scale and scope of Adobe. Now running a startup, I look at it and say “wow, 2 customers, that’s great!” Investors say the same thing. Someone recently commented, “I’m impressed you’ve gotten customers without outside investment.” And it’s not just me, a panelist on BNN’s The Pitch congratulate Dalia Asterbadi (LinkedIn, @d_asterra) of realSociable on her partners and her user numbers. The best part is RealSociable hasn’t launched yet!
The reality is that getting customers to pay for something is really hard. Which is why when you’re starting out, everyone says going to take twice as long and cost twice as much as what you think. And it does, because its really hard to get early adopters. Silicon Valley is full of early adopters who help give traction startups. We need more of them in Canada.
I really believe that the best thing a community can do to help local economy is to support local businesses and startups. We can argue about how much companies like RIM matter to startups. But it doesn’t have to be all mergers, acquisitions and corporate venture capital funds. It is not about new headcount or stock price. It’s about curiosity to seek out new solutions to your existing business problems.
If you’re reading this, you’re probably interested in startups. Are you a founder? Do you work for a startup? Are you working for a larger organization? Here’s how you can help:
Taking selfish advantage of an economic situation
Look at your everyday problems. Are you struggling with accounting software, check out WaveAccounting. Everybody hates HR, have you checked out TribeHR? Can’t get your kids to do their chores, maybe HighScoreHouse can help make chores a game. Did you experience downtime because EC2 was offline for 5 days, maybe VMFarms can support you local and on EC2. There are a ton of startups with solutions to consumer and enterprise problems. It can be a struggle as a startup to raise your awareness event with early adopters. [Editor’s Note: There were 42 submissions and 5 accepted demos at the most recent DemoCamp. You can tune into the startup news sources like StartupNorth, NextMontreal, TechVibes and others. It can be a challenge but we’re working on better ways to discover Canadian startups. You can find early access to our redesigned StartupNorth Index of companies. It is currently running on our staging server, but the data model is solid an we’ll move all entered data to the production instance in the coming weeks.]
We need to build and embrace a culture of early adopters. Look at your business operations, where are things not working as smoothly as you’d like. This is where you might be able to find a startup that you can take a flier on to help you improve the broken process. This is a chance to help an early stage startup.
Become an early adopter of a startups product. Use it for 6 months and give it a shot. When you’re working for a fairly large company (employs more than 10 or so), you’ve got nothing to lose. [Editor’s note: Nothing to lose, other than your job ;-)]. Hopefully you will have found a product that makes you day-to-day responsibilities easier, smarter, faster, more enjoyable. You get to go home at the end of the day with a pay cheque, and hopefully fixed a broken part of your job with very little risk or cost.
And you might have helped seed a startup. It takes so very little to help a startup demonstrate traction. A few customers which can lead to new investors which can lead into job creation in the community. It’s a cycle of early adoption in that we desperately need to start in Canada.
Embrace your role as an early adopter
Nobody ever gets fired for buying IBM. This might be true. But you’ll be giving a lifeline and valuable feedback to an entrepreneur by choosing their products. One of the great thing about being a startup is that many of us are innovators and early adopters. Our mail has been in the cloud since 2005, when we embraced GMail (for the massive storage). The iPhone seemed like the best way to stop carrying an iPod and a Blackberry in 2007. We constantly seek out new and improved technology products. We need to embrace the same eagerness to try personal technologies in our organizations. Whether it’s new technology like Node.js or Cassandra, or a new way to track real-time team performance (looking at your Rypple).
For startups traction is the new black. And it’s up us as middle managers and executives to seek out novel solutions. And in becoming a customer you might have just helped the next Facebook/Google/Oracle/Microsoft/Apple/etc.
What new products are you using that are reshaping your business?
Editors Note: This is a guest post by first-time entrepreneur Mike Potter (LinkedIn, @mike_j_potter) who previously was a Marketing Manager at Adobe, a project manager at Mozilla and an engineer at an Ottawa area startup. Mike has spent time running marketing programs for a large organization and has realized that power he held for many early-stage startups.
Ready to launch this summer? The clock is ticking on a great opportunity to launch your startup at the GROW conference.
Startups from across Canada can compete for a chance to Launch at GROW. 15 startups will be chosen to showoff on August 17 and the 4 most popular startups will have the opportunity to pitch on stage at the full day conference August 18. Over 600 attendees including top tier investors, entrepreneurs, and influencers from Canada and Silicon Valley are attending.
Less than 48 hours remain to submit a pitch. Upload a short video or photo with a description of your company here: http://launchatgrow.strutta.com
Last week Tim Ferris, of 4 Hour Work Week fame interviewed the guys from Pivotal Labs and learnt the secret of their success – pair programming! It was a very thought provoking piece on how to get stuff done.
Well here in Canada we have our own super hot mobile dev shop, Xtreme Labs, @xtremelabs, who are absolutely killing it, picking up huge customers like GroupOn. The guys at Xtreme Labs are also infamous amongst the tech scene for being pushers of pair programming.
Now at Peek, where I’m CTO, we are all “Lonely Hero Programming” all the time. Our “bus count” is precisely 1. If somebody died tomorrow you know what I’d do? I’d hire somebody new!
The Best Way To Program – By Vinoth Chandar, Some Rights Reserved
So, being from this totally opposite world to pair programming, I wanted to learn a bit more about why a company would choose pair programming, and I thought I’d start up a friendly dialogue with Farhan Thawar of Xtreme Labs to gather this thoughts.
Dan: Hey Farhan, how are things? I’d love to hear more about how you guys program at Xtreme. How are you setup?
Farhan: Our work environment is what I call an Agile Team room. Super low cubes, everyone in one area, with programmers focussed in a particular technology seated close to each other (so iOS devs sit together, Android devs sit together, etc.).
Dan: I’m going to start right off the bat with some basic math. If I have two people solving one problem versus two people solving two problems, doesn’t that automatically make me less productive? You know 1+1=2? How can I as a lean running startup afford to be half productive???? You guys have to pay your 2x workforce in real cash, right?
Farhan: So the simple math is misleading, i.e. that 2 programmers working on the same task is less effective. For example, most agile shops typically get 4-5 hours of coding done per day. The rest is spent in email, meetings, Facebook, Twitter, Youtube, reading blogs, etc. With pairing, we can focus our folks for 8-9 hours together to get a full days work done. Yes, it’s 8-9 hours / 2 = 4-4.5 hours of coding each, so at a minimum it’s the same hours. However, we have instant robustness (bus count), higher quality (i.e. less hacking), instant knowledge transfer (two people touch every line of code).
Dan: I am a programming god. I go on tears for 2-4 weeks where I am an absolute machine. Knuth himself would have a hard time keeping up with me as I weave around in my language du jour (i.e. Haskell, gods only program in Haskell.. the language of the heavens). The last thing I need is some assclown developer tethered to my leg slowing me down. How do you handle god coders like me in pair programming?
Farhan: Lol, badass programmers get better by pairing, just one example: http://cycle-gap.blogspot.com/2007/09/extreme-pair-programming-guy-steele-and.html. The reason is that it’s an intense learning environment, much like apprenticeship in the old days (you apprenticed to learn your trade). There’s no better way to get better and faster at your trade than to work with someone else who is as smart as you are.
Dan: How does this work if you work on a lot of projects? What if you are doing maintenance on a few projects as well as new dev’t on another project? We have lots of guys who probably touch 2-3 projects on any given day? Do they have to find their pairing buddy for each project every time?
Farhan: So the key is to not swap projects often. Almost 100% of our pairs are on a single project for the entire week. So week to week things my change (most time they don’t), but our devs are focused just on one project, on one platform. We do have R&D pairs and a Sustained Engineering pair who focus on multiple updates and fixes, but they aren’t dedicated full-time to any project. Folks also don’t find a pair, they are allocated before the week starts. We take tons of feedback on pairings and it’s very easy to see pairs that aren’t working well (they don’t talk much, or one person is driving the whole time)
Dan: In a debate in my company a great coder I know basically said something like this “don’t most coders do pair whiteboarding/pair designing anyways? By the time it comes to actually coding, isn’t that the trivial part?” Lets pretend this is a law office or consultancy shop, would you pair (i.e. do teamwork) at the strategy phase/problem solving phase or would you pair during the document creation phase?
Farhan: So the coding isn’t the trivial part, as the end product is based on the code. It’s almost like saying the ingredients and the recipe are the hard part but the cooking is trivial. It’s not (and I know, cause I can’t cook for shit). You want to write code that is elegant, understandable, maintainable, etc. and pairing forces that as two people have to understand what is going on at all times.
Dan: Have you guys ever tried doing like a race? Put two coders doing 1+1 vs two coders pairing on the same project? Should we try to sponsor this type of event?
Farhan: Bring it. We’d love this. Don’t forget, ACM programming competitions only use one computer 🙂
Process Matters
So here’s my take overall. Process matters. Even for dev teams of 1-3 people selecting the right language, technology, tool chain, and software process make a big difference in productivity and quality. Software engineering has improved by leaps and bounds over the past 5-10 years. Here are some of the best changes:
Opensource software and the explosion of re-usable software components
Iterations and demos
Continuous Integration, build servers and automated test suites
Continuous Deployments, i.e. the newer devops movement
Explosion of tools & infrastructure in the build, test, deploy area (think of tools like Heroku, Chef, Capistrano, build tools, etc)
Test driven development, test automation & significantly improved testing frameworks
(Sometimes I write in ANSI C on proprietary embedded plaforms, where the tool chain and quantity of re-usable code is a fraction of what I want. You take for granted how much Java, Ruby on Rails, Python, PHP, etc have been built up.)
These days, I rarely come across startups that haven’t adopted most of the above to a certain degree. And pair programming, truthfully its just not widely adopted compared to the list above. To me pair programming seems to be an overkill solution to solve the real programming productivity problem – communication. Engineers are classically trained to solve problems independently (though this is changing at the university level finally). Dr Amol Sarva, CEO at Peek, always mentored me with the following advice on communication, picked up during formal structured problem solving training at McKinsey.
“Basically there are three stages of any problem where one can communicate and practice team work:
1. Structuring – during framing of the problem. What are the steps I am going to take to solve this problem? Read the internet, talk to an expert, write quick hacks to test it, etc.
2. Solving – during solving the problem. “Hey, I did this and this and here are the raw results, interesting, right?”
3. Synthesis – communication while synthesizing the results of problem solving. “Hey guys, I solved this, here’s how. Code is checked in.”
Engineers classically wait until synthesis to solve the problem. Which is too late. Others, (e.g. your classic ice-breaking consultant) do too much communication during structuring.”
Pair programming forces engineers to communicate much earlier on in the problem solving process. Which is good! It also forces them to communicate across the whole problem solving spectrum from structuring to synthesis. Also good! But god it sure feels like an inefficient oversolve to the problem. Managers can bake in communication to their dev process without forcing pair programming in my opinion.
Having said all that, I am always willing to try something new (good engineering demands experimentation and learning), so we are going to try pairing it up on a project at Peek and see if it works well or not. I’ll report back the results.
I’d love to hear what others think. Is pair programming the real deal, have you found it to be more efficient in getting your code on? Or do you like to pound it out solo with headphones and your favourite hoodie?
