11:25 AM
Commentary
Driving Quality at Scale Through Pair Programming
In today's hyper-connected, click-speed environment, a single coding error in a critical financial system can have break-the-company repercussions. In 2011, for instance, the Securities and Exchange Commission (SEC) levied a $25M penalty on an investment firm after a software program applied the wrong decimal-to-percentage conversion in its portfolio risk estimate, a seemingly minor error that caused about $217M in losses to more than 600 client portfolios. And in June 2014, the program behind the Institute of Supply Management's monthly purchasing manager's index inadvertently set off a 35 point drop in the Dow Jones after it accidentally used the wrong month's data in its calculations. With financial institutions becoming ever more digitized and with billions of dollars at play every day, the risks of coding missteps are growing in number and severity.
CIOs of financial institutions are well aware of these risks, of course. But, despite the high-profile nature of some strategic software projects, there is often very little differentiation when it comes to quality assurance practices. Big projects may get more resources and status review meetings, but the standard review protocols remain largely the same. That can work well for routine projects or those with longer lead-times, but many new, mission critical software initiatives come with tremendous complexity and accelerated time-to-market requirements that require a different approach.
[Optimizing the Manufacturing Process in Development]
In response, some IT organizations are getting closer to the source and looking to rid coding errors where they begin, at the developer level. They're embracing pair programming, a software development technique in which two developers jointly work on the same problem, each acting as a sounding board for the other. That kind of approach often allows teams to find creative solutions more quickly and produce software with fewer errors and greater reliability.
Using this joint problem-solving method, pairs take turns "driving," tapping away at the keyboard to write the code and "navigating," reviewing the lines of code as they're written and keeping the end deliverable in mind. The approach allows both programmers to back each other up in designing, innovating and trouble-shooting.
Pair programming can confer many benefits, among them better design, better quality software, and increased code readability. A recent survey that McKinseyconducted found teams that employed pair-programming improved time-to-completion by 20% and reduced defects by 40%, with benefits accruing throughout the application lifecycle. In addition to lower maintenance costs, pairs avoid over-production by developing acceptance and unit tests first. And they avoid "gold-plating" by writing just enough code to successfully pass well-defined tests. Because every task on a development cycle is explicitly agreed upon with the business users at the outset, teams can focus their time on the right areas -- redirecting efforts away from low-priority functionality -- and ensure the software delivers as intended, steps that sharply accelerate the development curve. Cross-training is also better, since role and project switching speeds the ramp-up time for new developers and allows skills to be distributed among the team. Managers like the accountability and collegiality that pair programming brings, as opposed to the lone-crusader working style typical of traditional development practices.
The financial services industry stands to gain particularly. Because this industry is characterized by significant risk exposure, pair programming can be selectively deployed to help with complex, rapidly evolving, business critical applications where time-to-market and quality are essential.
To capture these benefits, pair programming should be used in a deliberate way and scaled appropriately. Organizations have found the following practices to be helpful:
1.Launch a pilot program with a team that is already doing agile development. The most appropriate projects for pair programming are complex tasks that require significant problem solving where quality and time-to-market are primary goals.
2. Cultivate the right mindsets. This requires a top-down commitment to capability-building at all levels. Not everyone is suited to pair-programming. It's essential to attract people who thrive in collaborative environments and are comfortable with having their work reviewed at all times to drive adoption and roll out pair programming in multiple waves across the organization.
3.Design a transparent work intake and prioritization process.Invite business partners to "show-and-tell" and planning meetings for each development cycle to build support. The frequent participation of the business in regular progress reviews helps accelerate both progress and buy-in. The use of charts and other visuals, in particular, often makes reviews more accessible. To keep the programming process on track, pairs should be encouraged to take on tasks from others if they have time left during the cycle, but rewards must be tied to quality and not quantity.
Organizations that have used pair programming successfully not only reduce the risk of coding errors but help instill a work culture that promotes ownership and continual learning, characteristics that go a long way towards improving software quality and reliability.
Sanjay Kaniyar is Associate Principal with McKinsey & Company; Amit Rahul is an Associate with McKinsey; and Philip Wiltshire is a Consultant with Nationwide Insurance. The authors wish to thank Jason Patterson, Mark Vair, James Grafmeyer, Michael Jones and Tom Paider from Nationwide Insurance for their contributions to this article.
Tweet This