An Observation Of Pair Programming vs. Not

I’ve spent the better part of the last month doing remote pair programming with Joey Beninghove, on our current contract. It’s been great – the constant discussion, the driving out of features, one small step at a time, the realizations of when and where we need to refactor and restructure to move forward. I’ve loved it tremendously.

And then Joey was out for the last 2 1/2 days for various reasons and I was on my own. I spent part of that time working on another project. When I was working on this contract, though, I found myself to be less productive and far less apt to be “in the zone”, code and concepts flowing into and out of me like water.

The net result: I find myself far more productive when I am pair programming than when I am solo programming.

It’s a combination of a large number of factors, including

Fewer distractions: I don’t feel the need to connect via facebook or twitter when pair programming. partially because it would be rude. partially because i have constant contact with another human, satisfying that need to be connected.

Intense focus: I don’t want to let my pairing partner down or leave him hanging, so I am always thinking ahead and thinking around the scenarios we are currently coding. It creates a very intense focus on the work at hand, making it easier to ignore the rest of the world around me

Constant communication: even when I’m the one doing the coding, I will constantly talk about what i’m doing. I mumble and mutter and spit out little fragments of where i’m going and why. it keeps me on track, for one, but it also informs my partner. this gives him ideas on where i’m going so that he can help me adjust and prevent mistakes from being made.

Cohesion: two minds are better than 1, and the those two minds comes up with better solutions than either one individually. the whole is more than the sum of the parts. etc. it’s true, without a doubt. it’s easier to get questions answered and explore idea. it’s easier to do design work with another perspective available. it’s easier to figure out when the design needs to change and what should be worked on next. it’s all around easier because there are multiple perspectives looking at the same problem

Flow: the feeling of being one with the code, being “in the zone”, where the problem at hand is matched with the skill set and the work is engaging. It’s far easier to enter this state when all of the above items are at play. i honestly lose track of time most days – i won’t really have any clue what time it is while we are knee deep in the features, code and refactoring. it’s not until my stomach starts growling at me that i realize it’s lunch or getting close to dinner.

It’s really quite refreshing and amazing at the same time, to see how productive we really can be when pair programming. Sure, I got plenty of stuff done on my own for the few days that Joey was out. But, it’s not quite as well structured. Some of the method names are funny. I wasn’t sure if my ideas were going to work. I found myself distracted more often. I was conscious of the time, all the time. And, what I think is the largest point of all – I made more mistakes that took longer to fix, because I didn’t have a second set of eyes and knowledge looking at what I was doing, constantly. Just having another person watching what I’m coding and thinking about the next step is a huge benefit, in itself. It’s much easier for someone else, who is not currently writing code, to notice a misspelling or out of place comma, or to see that you’re in the wrong file or working with the wrong design.

It’s interesting to observe these things after having spent a month pair programming. It’s almost a revelation of sorts – like the things that I had always done and always been subject to when working on my own, are suddenly showing up as negatives in comparison. The experience of high quality pair programming is reshaping part of my own expectations of productivity, at this point. Now I just need to work on these when I’m not pair programming – cause let’s face it… I’m not always gong to have the luxury.

What do you think? What’s your experience with pair programming? Are you more or less productive, and why?

Sadly, I’m the only dev at my current gig. So I don’t get to enjoy these points.

Anonymous

Sadly, I was once as excited about pair programming… Now, after pairing in person 80% of the time for 2 years, I feel it’s a net loss.

People who get along well, lose productivity; people who don’t lose interest and motivation. Weaker developers drag down more senior developers, and equally matched developers get into chest-thumping matches.

All in all, quality code review and quality tests are far more valuable and cost effective than the tragedy of pair programming.

http://murrayon.net/ Mike Murray

I’ve seen many of the same advantages when I’ve pair programmed. But I’ve also thought of some of the same drawbacks when doing it all the time confirmed in the previous comment. So playing Devil’s Advocate, have you not see any disadvantages yet, Derick?

i’ve done pair programming in the past and experienced most of the same things Anonymous has (except the chest thumping… luckily – but i can see how that could easily happen). it’s unfortunate that this is the common experience that people have w/ pair programming.

in the end, it takes a pair that work well together and know how to stay focused and get things done. i think there are company and team cultures that know how to grow these skills in people, but it seems that it’s few and far between.

http://darrell.mozingo.net Darrell Mozingo

My team spent the first 4 months or so when we started our current project working together. 3 of us with a projector, passing around the keyboard. It was quite fantastic – we got a lot done and the information sharing was second to none. A couple of years later, I think we all have the best knowledge of that fundamental portion of the project (more than any other piece of it) because we all helped write it.

Unfortunately we only did it because we literally started from scratch and there was no other way for all of us to be working on it without stepping on toes. As the project has grown we started working on separate parts, and our individual knowledge of the system has shrank proportionately.

http://danny-t.co.uk DannyT

I’d be interested to know the setup you’re using for “remote” pair programming. Is this over IM, do you have a constant skype call for instance? Are you using some form of screen sharing?

http://www.pmscrum.com Wouter Dwanckel

@anonymous, Derick Bailey
Aren’t you throwing away the child with the bathwater?
It seems to me that the disadvantages are more coming from a lack of organization (no ScrumMaster to get things straight, no PM that takes care of what needs to be done), rather than from the characteristics from XP.

Wouter – can you clarify what you’re saying and why? how does that apply to the subject at hand? scrum says nothing about engineering practices, and i’m not talking about XP. pair programming is far more applicable than just XP. i’m not sure what your statements are referring to, other than an assuming your saying scrum is better than xp… which is fallacy (scrum and xp are different perspectives for different purposes. they are not “better” or “worse” than each other without a specific team and problems context) and irrelevant to the topic of the post.

http://www.lostechies.com/members/derekgreer/default.aspx Derek Greer

I’ve had some very positive experiences with pair-programming over the past year, having discovered some of the same benefits. It definitely keeps the pair on task and focused as a result of an increase in accountability. I’ve also found that pairing tends to place some added pressure to not let perfect become the enemy of the good. When I know of one way to solve a problem, but find myself struggling with implementing what I believe would be a better approach, I feel pressure to time-box the effort. If the alternate solution works, great. Otherwise, the known solution is chosen and the desired approach is explored later.

Concerning the comments made by Anonymous, I would argue that most of the issues he raises are made more visible through pair-programming, not caused by them.

Steve

It’s no so much a question about not being as productive on your own, the question is, were you less than 50% as productive?

Even if you both work at 55% efficiency on your own compared to when you are together, that still is better than the results you’d get with paired programming.

Also, how much of your productivity decrease was easily managed (like blocking twitter, facebook, et al from your machine) as opposed to not having your partner to lean on?

http://randomcode.net.nz Neal Blomfield

I can’t comment on pair programming vs. not, but a lot of your points about the downside of working solo mirror my current experiences.

I am working on a reasonably sized project at the moment and am the only developer on it ( I’m actually the project manager and BA to some extent as well but that’s another story ). During the course of the project I have found that it can be very hard to stay focussed, and when I strike a problem it usually takes significantly longer to solve the problem as there is no-one else around who can discuss it with me and provide insight from a different point of view. I think this problem is further exaggerated as I am the only developer around, I work for a small company – I am one of four and of the other three, one is a designer and the remaining two are SMEs.

Working solo I have also noticed that it is far harder to maintain a decent level of motivation, particularly as we head into the end of the first year of the project. Having worked previously in a larger ISV environment where even though you may have been the only developer on the project, there were always a large number of other developerss around, I have come to the conclusion that even when you don’t actively pair program, when surrounded by other developers you end up implicitly pair programming as you use those around you as surrogate pairs. I think it takes a very committed developer to maintain the same level of productivity when working completely solo as you get when working while surrounded with other developers or actively pairing.

Steve

I find it hard to stay motivated too, as shown by the fact that I’ve added two comments to this thread while at work.

So is a better question to ask: How to keep a developer motivated for 7+ hrs a day while sitting at a desk? I’d hope that Paired Programming isn’t the only answer to that question, but I can see the merits in it. It’s almost like having a workout partner in the gym.

http://xpinjection.com Mikalai Alimenkou

Pair programming is my favorite practice from XP set. It depends on context but sometimes you may be 10 times faster working in pair just because of avoiding wrong solutions and fixes. Discuss, test, implement, review. Great cycle. Working alone sometimes you ignore review step and definitely miss discussion step.

http://www.lostechies.com/members/derekgreer/default.aspx Derek Greer

@Steve

The benefits aren’t just limited to personal productivity. Pair-programming also leads to better quality code, style consistency and solution and technical knowledge homogenization (especially when practicing promiscuous pair-programming). Concerning keeping oneself focused, studies have shown that pair-programming reduces the likelihood of being interrupted by others. For some reason, people are less likely to interrupt people working together than to interrupt someone working alone.

I’ve also personally found that pairing tends to improve a lot of little social skills as well. Constant communication tends to do that. When programming with others, there’s also little hiding any deficiencies you may have which can be hard on the ego, but ultimately makes us better developers. Overall, I’ve seen little downside as long as personal hygiene isn’t an issue :)

Even assuming this is all true (which is another conversation entirely), there are plenty of other mechanisms that can achieve the same results without Pair Programming though. And by “other mechanisms” I mean “cheaper”. For example code reviews can improve code quality, standards/snippets/.templates can guarantee style consistency, etc.

The hardest pill to swallow for management is “So, let me get this straight, these guys make six figures, and yet I need two of them to work together to code up a few web pages?”

Again, as a manager, unless I’m getting more than 200% efficiency from a pair of developers (granted, that’s incredibly difficult to measure), I can’t sell the idea to MY boss, let alone sell it to the CTO of my company.

J.R. Garcia

@Steve

“For example code reviews can improve code quality”

So, how are you doing code reviews? If you find flaws in their code, are they going back and fixing it? Seems like it would be costly to have someone spend a significant time coding something and then having to have someone review it and then having to have someone go back and rework it. Not to mention it would probably decrease morale.

Nitin

Based on experience, would be difficult to summarize that pair-programming is best always. If the programmers themselves are disciplined, focused and a bit experienced, I see that pair programming is usually counter-effective.

-Nitin

Nitin

….one additional point to always remember : we always had great good quality code written even before the advent of pair-programming :)

http://www.approvaltests.com Llewellyn Falco

I pair constantly. It’s amazing.

The main key to success vs failure lies in the amount of communication and collaboration between the pairs.

To this end, I always obey the rule “for something to get from one persons head to the computer, it has to go thru the other persons hands”

Do this, I have not found mis-matched talent of pairs to be an issue.

Steve:There are many studies that show that the velocity of pair programming is equal to the velocity of 2 programmers separate, but the bug count is ~60% less.
The question you should be asking is “If these guys cost 6 figures, how can I get the most out of them?”

GP expert developer

I always pair program with my imaginary friend Google :P

One of the best ways to do it. Novices might enjoy pair programming with other people. The real zone can only be achieved solo.

It is useful to have colleagues or friends to talk to sometimes, but if there are none around – forums might help.

James

Of course you found pair-programming “better” – it’s what you usually do. 2.5 days SP practise after years doing PP isn’t going to work: You will miss all the usual “comforts” of PP and will find it harder to concentrate. Most people who say “XYZ is the best/only way” are usually poor at applying other approaches. A truly good programmer will be comfortable and efficient working either way, and will use the best approach for the circumstances.

There are times when two brains are undoubtedly better than one. But there are also many periods in a project where two programmers can get twice as much work done to the same quality level when they work independently. If you learn how to be good at SP, you won’t need to tie up another programmer all day when coding up something simple.

Getting the best out of yourself is not a case of choosing one approach and rigidly applying it to every situation – it’s becoming a master of many approaches and using the best one for each situation.

James

Of course you found pair-programming “better” – it’s what you usually do. 2.5 days SP practise after years doing PP isn’t going to work: You will miss all the usual “comforts” of PP and will find it harder to concentrate. Most people who say “XYZ is the best/only way” are usually poor at applying other approaches. A truly good programmer will be comfortable and efficient working either way, and will use the best approach for the circumstances.

There are times when two brains are undoubtedly better than one. But there are also many periods in a project where two programmers can get twice as much work done to the same quality level when they work independently. If you learn how to be good at SP, you won’t need to tie up another programmer all day when coding up something simple.

Getting the best out of yourself is not a case of choosing one approach and rigidly applying it to every situation – it’s becoming a master of many approaches and using the best one for each situation.

Billy

I’m sure that if you get two people that love what they do and enjoy each others company that this is amazing. I could see that being the case. Making this kind of change to your development schema will cost a lot up front. The costs of having two guys on one computer is an obvious place to look for problems, but no one on the board has mentioned the fact that some people, like me, are out there that would quit that job as soon as possible. If I didn’t, security would have to walk me out eventually as I would be ready to slug someone that is over my shoulder as I work. I don’t mind getting together on a whiteboard and hashing out ideas, but I refuse to have someone sitting right there while I implement the solution we decided upon. Think about it. How many times have you been to user group meetings where some idiot savant down front picked apart every single little detail of the presenters code while missing the point entirely? What’s worse is that some of the picking is about things that are personal preference. Having that in my face would drive me absolutely insane.

Scott

@Steve,

I agree with your point about selling it to management.

To all,

I think the change in work style is more important than what the change is… moving to or from pair-programming is a change that re-invigorates. Remember the old study about turning the factory lights up and down?

Steve

@JR.

“So, how are you doing code reviews? If you find flaws in their code, are they going back and fixing it? Seems like it would be costly to have someone spend a significant time coding something and then having to have someone review it and then having to have someone go back and rework it. Not to mention it would probably decrease morale”

I don’t think you really understand code reviews. Now, with tools that are available, it’s very easy for people to review code and make comments directly in the code, or just fix up the issues themselves, all within a fraction of the time it takes to actually do the code. Also, everywhere I’ve worked we’ve had code reviews and there has never been a moral issue with it, it’s actually standard practice in most software shops.

Kyle Baley at Codebetter has a good article on how to do code reviews the “right” way:

Where are these studies? How many were there, how did they do the control? I mean these questions seriously. Where I worked I was pushing Unit Testing (since we didn’t do any), and my boss came straight out and asked me to prove that Unit Testing was cost effective. I had to go looking for white papers, studies, anything on the subject and for something so “important”, you’d be surprised how few studies there really are on the subject. Also, most of the studies were on TDD, not specifically on Unit Testing.

Personally, if there are so few studies on Unit Testing, I imagine there’d be less on PP. A quick check on Google has some studies from 2000, but other than that, not much. I have a hard time believing that working on their own developers will introduce 60% more bugs into a system, but that’s just me.

Again, I’m not saying PP is bad, or wrong, or anything of that nature, but there needs to be more than just anecdotal evidence before large companies would even think of adopting it.

Steve Again

Further to my point, here’s the second paragraph from Wikipedia on PP (as with everything form Wikipedia, YMMV)

However, a 2007 meta-analysis concluded that “pair programming is not uniformly beneficial or effective” because many other factors besides the choice of whether to use pair programming have large effects on the outcome of a programming task.[7] The meta-study found that pair programming tends to reduce development time somewhat and produces marginal positive effects on code quality, but that pair programming requires significantly more developer effort; that is, it is significantly more expensive than solo programming. The authors suggest that studies of pair programming suffer from publication bias whereby studies that would not show that pair programming is beneficial were either not undertaken, not submitted for publication, or not accepted for publication. They conclude that “you cannot expect faster and better and cheaper.”

Alex Kashko

Pair programming can help but having people work on something for a fixed time then rotate the pieces of work ( preferably unpredictably) is probably better. And if two are working with one keyboard and screen the one typing should explain what they are trying to do. I agree it would drive me crazy to have to watch someone or be watched.

As to motivation the best thing is, perhaps, to work with an attractive partner of your preferred gender and orientation.

Since when did paying 2 people to do 1 person’s job become good business practice? It seems to me that the ‘factors’ that raised this person’s ‘productivity’ are simply not engaging in bad habitual work practices, e.g., seeking distractions instead of focusing on the work at hand, lack of focus overall, talking constantly (another form of self distraction), 2 weak minds will produce a weak solution, failing to assume responsiblity for placing oneseld into the ‘flow’.
Isn’t a good education, and proper self discipline, pre-requisites to being a professional anymore?

http://www.blackfalconsoftware.com Steve Naidamast

By far, after 35+ years in the field and still working, “pair programming” has got to be the stupidest thing I have heard of.

Except for a 20-something, who in their right mind would get all excited about doing what is individual labor with another person at the same machine? It can’t be serious work since real software engineering takes a great deal of concentration…

Billy

Chuck C,

It sounds like you are either a manager; someone that lives, breaths, eats, etc. their job; or someone that writes payroll programs for a living. Some people find distractions to step away from problems. Your mind goes down a path so long that it has lost sight of the forest. Pair programming can alleviate some of that by having someone else look at it with you and provide suggestions of different paths.

Also, if you look at requirements for a group of people to be considered a civilization, you will find cinergy to be one of them. It is considered extremely important in the development of that civilization. The same idea is focused on in PP. With two people constantly discussing the problem, they either push each to be better through competition or collaboration. The thought process is that if you maximize that cinergy by pairing programmers together you will see a significant rise in productivity and quality. This is, of course, a subjective outcome. I am proof of that as my work tends to suffer when someone is over my shoulder or making comments every three seconds that have more to do with personal preference than being constructive.

a few of the more recent comments are borderline abusive and/or insulting… keep it nice, keep it discussion oriented, or i’ll close the comments on this.

also keep in mind that your experience is your own – not anyone else’. don’t assume your experience or preferences are the only ones that are valid, either.

Ken

I have never PP’d. It looks like an interesting concept. I have experienced the advantages and disadvantages mentioned for PP in other situations. The best situation I’ve had for getting work done may not have been the most productive, but it certainly was for the situation we were in. A three person team writing in a language none of us used before, in a new OS to us, but ancient and not as easy to use as the OS we were used to, transactional processing. We had 3 months to produce a completely new application. We broke the app into pieces, met daily, went over what we produced the day before, agreed what we would do for tomorrow, read as much as we could about the new language. That focused our interest into producing the code so we don’t dissappoint the next day, nearly immediate feedback.
The problem with code reviews is that it feels like I am the only one reading them because I don’t get feedback on my code reviews and the only one who seems to be finding logic problems in others is me.

Dustin

I personally like to PP. I find it more enjoyable compared to going it solo. Not that I have an issue with either method. I don’t however think that lines of code per day is any different as a pair or solo. I do however find that we get much fewer support calls on features that was coded as a pair. This is an interesting comment that most might find hard to understand. But please consider that my dev group works local to the company and does little testing on new features before release. While fixing bugs is the side effect of this, we have far fewer bugs to fix when we PP.

I also see many of you commenting on 2 people 1 keyboard. I do see how a co-pilot in the cockpit can help a little, but that is not how we PP. Each of us have our own workstations, we sit side by side and use real-time editing plug-ins to work on the same code at the same time. We communicate with each other about what is going on what we are doing and while both of us work on the same feature or function at the same time we often work in different parts of the code.

http://awkwardcoder.com Byron Sommardahl

Pair programming is an exercise in humility: it takes two people who DON’T think they are better than the other to pull it off. If this balance is off, it doesn’t seem to work and the productivity loss that people mention absolutely DOES happen. However, as Derick mentioned in his article, when things are going right, it’s a net gain. It’s all about the people involved.

I’ve done PP on my current project and it was a great help. I came up to speed on some very complex code in half the time it would have taken solo, and when the other person left, I felt confident in being able to take over. I focus better, and even when I’m falling asleep, the other person can pick up the slack until I get myself into gear. We switch places that way a lot, helping motivate when the other is having a slow day.

http://www.lostechies.com/members/derekgreer/default.aspx Derek Greer

@Steve

“… there are plenty of other mechanisms that can achieve the same results without Pair Programming though. And by “other mechanisms” I mean “cheaper”. For example code reviews can improve code quality, standards/snippets/.templates can guarantee style consistency, etc.”

I don’t disagree that other processes exist that can help improve quality and consistency, but through my experiences I’ve come to believe that many of goals of such processes are more effectively achieved through the practice of pair-programming. Post development processes such as code reviews, cross-training, etc. tend to become less necessary, and mandated adherence to standards tend to be replaced by more organic homogenization of best practices and preferences, but none of what you’ve listed are necessarily mutually exclusive to pair-programming.

Concerning the claim that these other processes are “cheaper”, this may or may not be true depending upon a number of factors, not the least of which is the needs of the business. Some of the processes you mentioned, particularly code reviews, provide only a fraction of the benefit that pair-programming can and depending upon the type of application you are developing they may prove to be a less expensive route to achieving that subset of benefits. They may also prove to be a more expensive route if the issues for which pair-programming would have aided in begin to surface. I’ve always liked the analogy of the Amish and IKEA’s construction methodologies. One emphasizes quality, the other affordability. Which is better depends upon your needs.

‘The hardest pill to swallow for management is “So, let me get this straight, these guys make six figures, and yet I need two of them to work together to code up a few web pages?”

Again, as a manager, unless I’m getting more than 200% efficiency from a pair of developers (granted, that’s incredibly difficult to measure), I can’t sell the idea to MY boss, let alone sell it to the CTO of my company.’

This begins to enter into the realm of agile vs. defined SDLC processes which is probably too lengthy to discuss here. What I will say is that, ideally, development teams are empowered to chose the development process that are best suited to the needs of fulfilling their responsibilities. At worst, those at more executive level positions shouldn’t be concerning themselves with how the bricks are getting laid, so to speak. One might also ask, “So, I’m paying these guys six figures and they still need their hands held? Aren’t you hiring professionals?”

Steve

@Derek,

“Post development processes such as code reviews, cross-training, etc. tend to become less necessary, and mandated adherence to standards tend to be replaced by more organic homogenization of best practices and preferences, but none of what you’ve listed are necessarily mutually exclusive to pair-programming.”

Agreed, but PP is just the most expensive (or at least like so) solution to these problems. If my task is to get the the airport, PP is the stretch limo of options, while “cheaper” methods are the cab. Would I prefer to take the limo? Sure, but it’s hard to justify the dollar amount when there are other forms of transportation that do the job nearly as well.

“This begins to enter into the realm of agile vs. defined SDLC processes which is probably too lengthy to discuss here.”

I don’t see it that way, it seems that most of the reasons listed for doing PP are more related to distractions, which I don’t think is SDLC related, its more developer related.

Let me put it this way, if I have to go to my boss and explain that it takes PP to keep developers from being distracted and working, I might as well be saying “fire me” while having a big L on my forehead.

http://www.lostechies.com/members/derekgreer/default.aspx Derek Greer

@Steve

Again, whether other processes provide a more cost-effective strategy depends upon the circumstances and goals you’re trying to accomplish.

In my opinion, a better analogy would be the needs of a family settling in the wilderness in early America (think little house on the prairie). After choosing the home site upon arrival, the first thing that needs to be done is to establish a shelter … and fast. While some discrimination will be exercised when building their temporary shelter, any measures taken will be made with the temporary needs of the structure in view. Once established, a homestead will be constructed which will better withstand time and the elements.

In some circumstances, it can be faster and cheaper to develop a solution without maximizing the engineering and quality assurance best practices of the industry, and depending upon the needs of the business this may be the right solution. For long-lived endeavors, such strategies can prove to be more expensive when considering the total cost of ownership.

Concerning my statements regarding the SDLC, the point I was trying to make is that getting buy-in from front line managers, managing directors, vice-presidents, etc. on a particular development methodology is a larger topic. In my opinion, whether the development team should be, for instance, employing code reviews or pair-programming isn’t ideally a decision that should be being made by upper level management … or even the development manager. If you are paying a team of engineers six figures to accomplish a task, get out of their way and let them do their job.

Steve

” If you are paying a team of engineers six figures to accomplish a task, get out of their way and let them do their job.”

I think that might sound right when you type it out, but it’s not reality. If you just got out of developers way (and I am a former one), people would just do whatever they wanted. Dev A would test, Dev B would also test, but use a different tool, and Dev C would just sit on Facebook all day. In a one or two person shop, it might work, but I have hundreds of developers that I am responsible for (either directly or indirectly). I can’t just get out of their way or nothing will ever get done, and no standards will ever be followed.

I know the purpose of this post by Derick was just about some personal observations, and we’re well off that beaten path. But if there are any real PP studies that can’t easily be ripped to shreds, I’d love to see them. As I mentioned earlier, I have to “prove” everything before I’m allowed to implement it, since you can’t just say “Let’s give Unit Testing a try and if it doesn’t work in a few weeks, we’ll kill it” when you have over 100 people involved.

In short, I find its benefits overstated and the downsides overlooked. Also, the attitude that if you don’t like PP, then you must have some superiority complex (evident in some comments here) is ridiculous.

Pairing requires lots of preconditions to be met to work properly, and even when it does, the loss of productivity and newly gained inertia are by far greater than the gains in code quality or learning.

My Podcast Hosting Service

My Screencasts

My eBooks

Building Backbone Plugins

Stop wasting time writing boilerplate code. Learn how to extend backbone the smart and scalable way!