Efficiency of pair programming – experiences from a real project

Without a doubt we have all heard, that pair programming is a good idea for various reasons. Most often those who have had experiences with actually practicing it for a while recommend it fondly.

The argument against it, that it is too expensive with two programmers working on the same thing, gets countered with the argument that you get higher quality code faster. But as with most of the “truths” of software development, it is based on assumptions and gut feeling and often very little data. One of the reasons for this is, that you rarely develop the exact same thing twice, just for the sake of experiment. Creating mobile apps is an exception though, since we often develop the same native app for both iOS and Android.

On a recent project we developed an MVP of a mobile app for a customer and circumstances would, that one app was developed through pair programming and the other through regular 1-dev programming. Therefore we ended up with a good opportunity to evaluate how pairing stacks up against regular programming.

This particular project was unique because development for both platforms was carried out in parallel. Usually one platform takes the lead (and the hassle of figuring out all the little details that was not specified to begin with) while the other follows. This means that the time spent on the leading platform is much greater than the following platform. But since the preparation phase had been really thorough in this project, both apps could be developed in parallel.

The team

The team consisted of a UX designer and three experienced developers, one full time Android dev, one part time iOS dev and one .NET dev moving into iOS development.

The app

The app is fairly simple. Three screens with mostly static content and a profile page, where the user enters personal information. The app also contains functionality to place phone calls, initiate emails and open web-links in a browser. The personal information on the profile page affects some of the content and links/phonenumbers.


The pages have the same design for content across iOS and Android but the navigation is specific for each platform. iOS uses a tab bar while Android uses a burger menu and navigation drawer.


Before the development started there was a preparation phase, where the requirements were created, graphic and ux-designs were made and most questions were answered so rapid development for both platforms could start. The Android developer and UX designer facilitated the preparation phase.


Development of the app was done simultaneously on both platforms.

The Android dev worked alone and the .NET dev worked on the iOS app as a combination of a client project and competence development. About 1/3 of the total time spent on the iOS app was done as pair programming with the experienced iOS dev and the remaining 2/3 was done by the .NET dev alone. Therefore we expected the iOS project to use more time altogether, after all the .NET developer was doing most of the programming alone and with previous iOS experience limited to a bit of Xamarin.Forms.

Comparing results

A quick survey around the office shows that Android and iOS development can usually be assumed to take the same amount of time. Practical project experiences range from “Android is normally slower” to “iOS took twice as long”, but all agree that the ballpark estimate is the same for both platforms, and with this project being fairly simple, involving no complicated features or design choices that alleviated from platform standards, this assumption was reinforced.

After developing the first version of the app and presenting it to the customer, we took a look at the hours spent. At this point the two apps were not yet ready for app-store (final content and translations were not yet done) but feature development was finished and both apps appeared to be the same level of quality.

The number of man-hours spent shows that each app had taken approximately 100 man-hours to develop. We had expected the iOS app to be more costly, because two developers were assigned and it was part competence development.

These findings could be extremely beneficial in other projects too, since the pair programming approach seem to drastically minimise the costs of learning the ins and outs of a new platform. Naturally more experience is needed to make clear conclusions, so combining client projects with competence development via pair programming should definitely be encouraged when it is possible.

Since this project was very low on complexity, one might also assume that the benefit of pair-programming would be even greater on more complex projects (most projects, really), where having two sets of eyes the code is normally assumed to make a big difference.

Leave a Reply