Pair Programming and the benefits of IT collaboration through DevOps

ecs-admin 20th November 2015

Although it might not seem like it in some organisations, IT is a collaborative discipline. Even before DevOps started rewriting the book on the way software is developed, the average software development firm depended on different departments working on different aspects of the same project, and hoped against hope that everything would come together in the end. In a DevOps culture, much of the hoping and guesswork is eliminated by bringing dev and ops onto the same playing field. But for an industry that relies so much on teamwork, there’s no such thing as too much collaboration in IT. In this blog, we’ll take a look at the practice of pair programming, what it means, and how it could benefit the flow of work in your organisation.

How exactly does pair programming work?

Like any other feature of a DevOps implementation, the specifics of how pair programming works in any one organisation may be radically different from the next. However, there are some high-level points to bear in mind to ensure you’re going about things in the right way. In a typical pair-programming setup, two developers work from a single workstation. One developer works as the driver, and writes the code, while the other acts as the pointer, observer or navigator, and reviews each code as it is entered. The observer is also responsible for considering the strategic direction of the work and considering any future problems that may arise, or improvements that could be made. The driver, on the other hand, is given as much space as possible to focus his or her attention on the pragmatic task of completing the required task.

So, with that out of the way, let’s look at some of the benefits of pair programming.

Two heads are better than one – and it shows in the quality of your code

It might seem logical that assigning two developers to a project would result in a 50% slower development speed, but studies have shown that this isn’t the case. On average, paired developers take just 15% longer than individuals to complete a task, but a corresponding increase in quality of around 15% makes this time difference negligible. In addition, collaboration in IT is a great way to consistently come up with more diverse and innovative solutions to any given problem. This could be the result of different developers bringing different experience to the same problem, good creative chemistry between employees who have been paired, or the natural consequence of pairing two developers who approach the task differently by virtue of their role in the organisation.

Better design quality results in better economic performance for your organisation

Improving the quality of your software projects is a goal in and of itself, but the unfortunate reality is that it doesn’t automatically translate into good ROI. But when you factor in the other costs associated with long design times, like hotfixes and debugging, the cost benefits of collaboration in IT through pair programming start to add up. A major contributing factor to this is the performance-increasing aspect of pair programming – by pairing your developers up, the driver is less likely to get distracted or waste time looking up something that he or she could quite easily ask the observer instead. As an example of the types of savings made possible through pair programming, IBM reported spending around $250 million on repairing and reinstalling 30,000 customer-reported problems in 2000. Even without factoring in inflation, that’s a huge amount of money to be throwing away without a good reason.

Team-building is as important as software-building – pair programming benefits both.

Pair programming is as much a team-building exercise as it is about improving ROI and software quality. An obvious benefit that comes with team building is in how it exposes members of your team to new projects and broadens the knowledge base of your entire organisation. But, depending on how you sculpt your particular pair programming system, it’s possible to tailor your system to fulfil particular objectives. For example, expert-expert pairing is a good way to pool the best minds in your organisation for a demanding project, but might leave the rest of your team without their star performers. Novice-expert pairing is a great way to impart your most senior team members’ wisdom onto new starters. Novice-expert or Novice-intermediate pairing is also an effective way of shortening the time it takes for new hires to become contributing members of your team, as they will have more opportunity for first-hand exposure to the way your organisation works.

ECS Digital has been implementing DevOps in organisations around the world for the past 12 years. We have extensive experience with DevOps implementations and consultation, and host regular Devops Training in London. To find out more about us, enquire about our training courses today.

Found this interesting? Why not share it: