Real-Time Collaborative Programming in Software Business?


Real-time collaborative programming describes a way of concurrent programming, where all developers in a software project can edit the source code at the same time, propagating the changes in real time. As this can be a very interesting approach for improving the collaboration between developers, it might be worth implementing such a technology into a software project in the industry. Even though there also exists an implementation of this technique for the programming language SmallTalk [1], in this blog post the Web-based collaborative Java IDE “Collabode” [2] is analysed on its usefulness in software business.

While there are a few advantages of this form of real-time collaboration in software engineering, such as improved pair-programming, the disadvantages outweigh them. As the main disadvantage is not being able to use a Version Control System (VCS) in a normal way, also the benefits of using a VCS are lost. In summary, the approach considered has too much drawbacks to use it in software business.


Screenshot of Collabode, Source: [2]

Overview of Collabode

In 2011, Goldman et al published the web-based Java IDE Collabode for real time collaboration in the browser, based on Eclipse. It makes concurrent editing of the source code files for an arbitrary number of developers possible. [3] The behaviour of the system is thereby similar to Google Docs, which provides real-time concurrent document editing.

Changes in the source code are propagated to the other developers as soon as possible, but with a certain error-awareness, so that a change is propagated immediately once it does not cause compiler errors. If a change results in errors, the change is kept in a local working copy, so the engineers do not break their common build. [4]

The underlying multi-user editor is Etherpad [5]. [4] It supports simple versioning and version access of single files, but other functions of a modern VCS are not included.


According to [3], developers can benefit from using this approach in the following ways.

Firstly, it is possible to ask colleagues for help for small code snippets easily (“micro outsourcing”. Secondly, it enables Pair Programming on different machines. Finally, this approach improves teaching possibilities. [3]

In addition to these points, such a collaborative system can be particularly helpful when developers are not in the same place. So Pair Programming can be achieved even if the colleagues are for example in different countries.

Furthermore, such an approach is improving the ability to teach new colleagues developing the product. As the new developer can work on his own computer while collaborating with a senior team partner, he arguably gets more involved into the learning process. Moreover, this is also more convenient for the senior developer and may therefore reduce a possible unwillingness to teach, as he is able to work from his own computer while teaching.

Finally, with Collabode a developer does not need to manually commit to a Version Control System, which saves time. [4]

Minor Drawbacks

However, there are several disadvantages of using this real-time collaborative programming tool:

Firstly, even though Collabode uses Eclipse as a basis, not the full Eclipse IDE is implemented in the browser-based user interface. [4] Therefore, some useful IDE features cannot be used with this approach.

Secondly, more communication is necessary between the developers. Considering the case that developer A is implementing something that uses a class that is being refactored by developer B in the same time, A might get unexplainable results. Therefore practically every developer in team must know what the others are doing at the moment. This communication overhead can lead to less efficiency.

Thirdly, the approach is not tested in large-scale projects, so there is still some research to be done here to be sure the system works in a large software project.

Main Disadvantage: VCS limitations

The main drawback of using this approach is that the normal use of a Version Control System is not possible. This section is focused on the most important reasons for using a VCS.

According to Somasundaram ( [6] ) the main advantages of using a Version Control System are the opportunity to keep different versions of the source code and the possibility to roll back to a previous state as a failsafe plan. [6]

Concerning the first point, restoring previous versions of single files is possible due to the functionalities of EtherPad. However, when changing multiple files in one change, it is not traceable that these individual changes belong to one logical union like when committing manually. It is therefore difficult to figure out a consistent state to roll back to. Furthermore, the lack of commit comments makes such an operation even more difficult. So, both main advantages of a Version Control System mentioned above cannot be used in a practical way in Collabode.

Moreover, since there are no commit comments, an important source of information is missing, for example which bug the change refers to.

Finally, this way of micro-committing everything automatically makes Continuous Integration very difficult. It is much harder to find a commit that breaks a test when there are this much uncommented commits.


While the real-time collaborative programming approach like implemented in Collabode is certainly suitable for teaching and pair programming, its usefulness in software industry is very limited. This is mainly the case because it circumvents the principles of committing to a Version Control System. If a company wants to benefit from the advantages of this new way of programming, it loses the much more important main advantages of using a normal Version Control System. Therefore I do not recommend using such an approach in a normal business software development process.

However, if a company focuses more on the improved collaboration and less on the benefits of using a VCS, using Collabode can be taken into consideration. Also a partial use of this system for training sessions in the industry can be advantageous.


[1] J. Jordan, “Wolf Pack Programming? | Cincom Smalltalk,” 2010. [Online]. Available: [Accessed 3 3 2014].
[2] “Collabode – Collaborative Coding in the Browser,” 2012. [Online]. Available: [Accessed 3 3 2014].
[3] M. Goldman, G. Little and R. C. Miller, “Collabode: Collaborative Coding in the Browser,” in Proceeding of the 4th International Workshop on Cooperative and Human Aspects of Software Engineering, New York, 2011.
[4] M. Goldman, G. Little and R. C. Miller, “Real-time collaborative coding in a web IDE,” in Proceedings of the 24th annual ACM Symposium on User Interface Software and Technology, New York, 2011.
[5] “Etherpad,” 2014. [Online]. Available: [Accessed 7 3 2014].
[6] R. Somasundaram, Git, Birmingham: Packt Pub., 2013




Pair Programming, Best Development Practice?

This discussion is a response to s1369981’s post, “Why Pair Programming is the Best Development Practice?”

In their post, the author tries to convince the reader of the benefits of pair programming, highlighting the positives that this agile developmental style brings, such as, increased knowledge sharing and project ownership, stating that:

“Pairing is about collaboration and teamwork, thus it will shine… [in] knowledge sharing and project ownership…”

Although, despite the author’s arguments, I’m not completely convinced of their stance, mostly due to the, exaggerated, claim that pair programming is the overall best development practice in all scenarios of programming development.

I think that while there are certain situations when it can be beneficial, (between two novices) extending this to every programming situation is not significantly justified.

The author doesn’t see this because they neglect to address:

  1. The economic downfalls of the practice.
  2. Developers’ natural opposition to this working style.
  3. The fact programming might not be so mundane, if you enjoy where you’re working.

These counter arguments that I present will show that the author has failed to consider these important points in their article and that they’ve been too general in their argument that pair programming is the best development practice for all situations.

But Work is Boring?

In the post, s1369981 makes certain claims, that I’m not particularly in agreement with, such as:

“… most programming tasks in a software company will focus on boring and repeatable tasks with very few of them being creative and challenging.”

This pessimistic view of what the programming world after university is like tends to suggest that the only hope for a programmer to have an enjoyable time is to pair up, therefore distracting you from your “boring and repeatable tasks”.

This solution of improving your enjoyment at your job would only ever be a temporary one, as the novelty of pair work wears off.

Finding a more exciting company according to your personal tastes in programming would help you to enjoy you work more, without needing the distraction of a partner to making it bearable. Also, by simply increasing your communication amongst members in the team, working on different projects, would increase team spirit and cooperation and make it feel much less like you’re working on your own.

I’m stuck!

Speaking from personal experience, while on my internship, I found that instead of any pair programming scenarios, the newcomers (or contractors) to the team sought out the help of more experienced senior developers when stuck, rather than pairing up with them while programming.

This practice produced similar benefits of a senior developer working with a novice, in that the more experienced developer could pass on valuable knowledge and use their expertise without feeling restricted by having to effectively babysit this new employee.

This also left the senior developer with time to apply their invaluable knowledge elsewhere by programming solo, where they would be able to maintain their high productivity. [1]

As mentioned before, having a pair programming situation amongst two novices or a novice and someone who is competent would be helpful because, on their own, they’d undoubtedly have a low production levels but together they can boost their learning levels and this allows new recruits to get up to speed quickly. [1]


Something not mentioned in the author’s article is the economic viability of mass pair programming, as the team would need to have more employees to manage the same amount of projects.

In controlled studies it was found that it wasn’t economically viable as only for simple systems was a significant decrease in development time found and no significant difference in correctness of solutions. [2]

In fact, in this large empirical study, Arisholm et al. found that the results did not support the general consensus and that:

“… pair programming reduces the time required to solve tasks correctly or increases the proportion of correct solutions.”

Instead, they discovered that, in general, there is an 84% increase of effort required from the programmers to perform the tasks prescribed correctly, where effort (or cost) is the total programmer hours spent on the task.

These empirical results give us a more concrete measure of the benefits of pair programming amongst a variety of levels of programmer and I believe this evidence to be more reputable than remarks from people who’ve tried out pair programming, as this is open to bias.

The findings back up the reasoning that for a team to be operating at the same level as they are currently, managing as many different projects as they are, they’d have to hire more employees to maintain this level of output even when the benefits of pair programming aren’t so great.

It ain’t all fun

The author’s conclusion takes a simplified view of the situation by suggesting it should be adopted because:

“Pair Programming is the best development practice, because it is fun!”

But as suggested earlier in the article, by the author, there is a lot of strong opposition to this with people arguing adamantly against this belief. [3]

So, certain people will not work well in pairs, no matter how many statistics or studies you throw at them and I believe that if it is going to be used in a team, it should be tried out for a certain period where productivity can be monitored.

As mentioned and described by s1369981, people should be also be educated in how to properly undertake the pair programming developmental process if they’re going to be working with it and this can help to eliminate common mistakes and incorrect assumptions made about the practice.

Once the practice has been carried out correctly, the management can get feedback from it both empirically and from the developers who tried it so that they can make a reasoned decision on whether it is a viable option for your team.

Here, developer input should be considered closely because regardless of whether it makes your programmers more productive, making them uncomfortable in their work environment will cause some people to quit.


There are some points in s1369981’s article that I agree with, such as, the fact that pair programming can increase knowledge sharing and project ownership in a team.

However, the application of pair programming to all forms of development is an overstretch due to the economic downfalls, some developers being opposed to paired work and the argument that only pair programming can make your job enjoyable.

I do believe that it still has its place e.g. between two novices in a company or for complex tasks, as it can help to improve correctness of code, but bear in mind that this comes at a price: overall increased effort. [1] [3]

Therefore, any adoption of pair programming should be evaluated on a case-by-case basis to see if it really is the “best development practice”.


[1] – Derek Neighbors, “Should Senior Developers Pair Program?”, November 2012, [Accessed on: 26th February 2014]

[2] – Erik Arisholm et al, “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise”, 2007, [Accessed on: 26th February 2014]

[3] – Matt Ervin, “Pair Programming (give it a rest)”, November 2013, [Accessed on: 28th February 2014]

Pair Programming: Will It Make You Hate Your Colleagues?



I recently interviewed for a company who believed in pair programming one hundred percent of the time on all projects. It got me thinking about how pair programming, on this scale, would impact me as a developer and whether it would actually be effective and useful. This blog post will explore and analyse the benefits and costs of pair programming one hundred percent of the time as a software development technique.

The Concept

Pair programming is an agile software development technique where two developers work together at the same computer. The developer who actively implements the program is known as the driver, while the other is the observer. The observer’s role is to continuously monitor the work of the driver to identify syntactic errors, spelling mistakes etc. The observer is also responsible for steering the design of the project in the right direction. Both developers switch roles frequently.

There are three possible pairing permutation when pair programming. Novice-novice, novice-expert and expert-expert.

The novice-novice pairing variation has shown an increase in productivity in comparison to developers working on their own [3]. The novice-expert variation makes for a great training tool to introduce a new hire to a development language or framework that they are unfamiliar with [5]. The expert-expert is a powerful variation and can lead to a boost in productivity.

However with each of these variations,  studies and developers [5] have both shown that pair programming is best for solving new, previously unseen problems. This is indicative that pair programming one hundred percent of the time may not be appropriate.

Reaping the Benefits

The aim of pair programming is to improve code quality and efficiency while simultaneously providing an outlet for developers to learn from each other.

Studies have shown that even pair programming by two novices is more productive than a solo developer coding on their own [3]. There are also definitive results that clearly show that code quality improves when pair programming is used. It has been shown to reduce defects by up to 15% [1]. Having the code the driver is writing be constantly reviewed by the observer leads, not only, to more errors being caught immediately. It is also more efficient to constantly review the code than to only review upon completion.

One of the nicest benefits of pair programming is team building.  It encourages better communication and collaboration. Programming is often depicted as a solitary task and developers as shy, quiet people. Pair programming, however, forces developers to actively work together which can lead to more productive teams, not just individuals . Most of the studies referenced below, point this out [1][2][3].

However, one key factor that is evident from all these studies is that they don’t seem to have considered what pair programming is like if it is being carried out one hundred percent of the time, all day, everyday. While it is true that developers don’t code all the day, there are a number of scenarios where pair programming one hundred percent of the time may not be the best course of action.

100% Pair Programming: Yea or Nay

While empirical studies prove that pair programming is one of the best things to happen in software development, I am not convinced by them. The one factor that they do not seem to take into account a great deal is  the ‘human’ factor.

“In the name of (short term) productivity” – Mark Needham [5]

The implementation phase of a software project is not all just about overcoming challenges. All projects have mundane and often trivial code that needs to be implemented to carry out the most basic of tasks. The problem is that the observer will just have to observe this dull, trivial  process without being able to contribute anything useful. Their skills could have been put to better use in implementing a critical piece of code, or another piece of trivial code which had yet to be implemented. The approach of pairing one hundred percent of the time can lead to a waste of a developers time and talent. This could slow down the development as there may be many other pieces of code yet to be implemented which could be implemented by the observer. This argument still holds when the developers switch roles.

Pairing all the time is also a terrible way for a developer to learn to use any development tools. Watching the driver make use of various tools, or watching them figure out how to use these tools is not educational. Some tasks need to be completed by the learner themselves to be able to fully understand them. This is similar to a person claiming they can play basketball because they have watched a few games on TV.

In addition to this, there is a time for individual work unhampered by the need when mundane tasks.

“You don’t want to waste their time. You don’t want to argue (unless the other person wants to as well). You give in more often than if you were working alone.” – Mark Wilden [6]

Pair programming depends on the abilities of two developers to successfully collaborate and work togethe. The studies below all assume that people will get along with each other the entire time. Perhaps this should be the case in a work environment as professionals are expected to put aside their feelings, but realistically that this is simply not the case. This is not implying that they may resent each other (they might), but they may disagree a lot when it comes minor design decisions. This may slow down the pace of implementation and in some cases lead to one developer believing that their opinion is not correct or worth taking into account. This can be quite demoralising, leading to feelings of resentment. This could be prevented if pair programming weren’t being carried out constantly and only major design decisions were discussed, leaving the minor decision to the coder’s discretion.

“Pair programming doesn’t encourage quiet reflection and exploration.” – Mark Wilden [6]

As a developer, getting a feel for the language and codebase is quite important when it comes to implementing designs. Just as children learn by trial and error, developers learn by exploring the code. Many innovative ideas can also stem from exploring the codebase; refactoring certain classes for example. However, if a developer never gets enough time to work their way through the code or language then they can never truly get comfortable with it.

The Bottom Line

Like Wilden and Needham, I think pair programming should be used in moderation. In my own limited experience as a developer, I faced days where my productivity was low. It could be argued that on these days pair programming all day would have helped this, but I don’t think it would have. Almost everyone who has has some work experience can relate to days where your brain does not seem to want to function properly. The mind doesn’t think straight; logic, which was always like second nature is baffling and even words escape you. On these days a developer just wants to get through the day. These unproductive days have always been compensated with extremely productive, slightly longer, working days. However if forced to pair program all day on such days then I’d have to say that it most likely would not have resulted in feelings of hatred, however it may have led me to associate negative feelings with programming with my pairing partner. This is not a failing on the concept of pair programming alone, in fact pair programming in small increments may help, but on human nature.

Pair programming is incredibly beneficial and should be used in moderation especially when used to exchange knowledge. It can make a great coaching tool and when used to solve a new, unseen problem it can help teams work together to design innovative solutions .  However pairing one hundred percent of the time should be approached with caution to ensure that colleagues do not develop mutual feelings of annoyance towards one another.


[1] D. Winkler, M.Kitzler, C.Steindk, S.Biffl (2013) ‘Investigating the Impact of Experience and Solo/Pair Programming on Coding Efficiency: Results and Experiences from Coding Contests’, Agile Processes in Software Engineering and Extreme Programming [Online]. Available at:

[2] Erik Arisholm, Member, IEEE, Hans Gallis, Tore Dyba˚, Member, IEEE Computer Society, and Dag I.K. Sjøberg, Member, IEEE (2007) ‘Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise’, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 33(2), [Online]. Available at:

[3] Kim Man Lui, Keith C.C. Chan (2006) ‘Pair programming productivity: Novice–novice vs. expert–expert’, [Online]. Available at:

[4] Alistair Cockburn, Laurie Williams (n.d.) ‘The Costs and Benefits of Pair Programming’,[Online]. Available at:

[5] Mark Needham (2011) Pair Programming: The disadvantages of 100% pairing, Available at: .

[6] Mark Wilden (2009) Why I Don’t Like Pair Programming (and Why I Left Pivotal),Available at: