Episode 43

In a perfect world, those closest to a problem have the tools and capacity to create the solutions they need. Whether delighting customers or solving an internal challenge, those on the front lines know most intimately the needs and requirements of the project. In the actual world, the expertise to develop the solution will be at least one, but possibly many steps removed from the problem, creating translation challenges that must be overcome. A disconnect between the people with the problem and the people with the skills to solve the problem is not a new difficulty, and there have been numerous methodologies, practices, and principles developed in the pursuit of generating high quality products with the fewest amount of resources. In this blog, I will explore how Pair Programming, a method to improve development quality, can be used to bring the development talent closer to the problem.

Pair Programming is a software development practice where two developers work together at one workstation. One Developer writes code while the other watches. Ideally, their roles switch frequently. One Developer might focus more on strategic elements of the development work while the other will focus on the tactical aspects. In this practice, development time is front loaded as two developers are being utilized at a single workstation, however the solution will have fewer defects and require less rework in the future than a single Developer approach. Pair Programming is a great method for sharing and expanding skill sets between developers as two individuals will almost always have different perspectives and approaches in solving a problem. Pairings can vary between expert and expert, expert and novice, and novice and novice. With this methodology we are assuming that the development pair is at least one step removed from the problem and the development is taking guidance from a product owner or business user.


Last blog episode explored the potential that Citizen Developers offer to organizations as we see expanding capabilities and capacity of low-code application development platforms. The goal of these systems is to empower business users to solve their own problems, however, as covered in a previous blog, the low-code tools have their own risks. Here we can use Citizen Developers and Pair Programming to bring development talent a little closer to the problem.

Now consider replacing one Developer with a Citizen Developer. At the end of the day, using low-code platforms turns into a development project once the scope expands beyond what is solvable with simple templates. For more advanced users of these platforms, there are “for Developer” tools that unlock powerful features that would typically be out of reach of the average Citizen Developer. In this form of Pair Programming each Developer would have their own workstation, where they are each coding together as a team, and responsible for the same feature or project. The coding roles are differentiated between competency areas, with strategic and tactical aspects of both business and technical requirements shared between the pair.

An example of a problem for Pair Programming with a Citizen Developer would be automating a sales lead documentation process where the Citizen Developer creates a Power Automate Flow to summarize the details of the inquiry and post this information into a sales chat channel. The Developer then handles the API integration with the organization’s CRM system. The Citizen Developer can document the requirements while simultaneously working with the Developer to work out the best technical architecture for the solution. The Developer can experience the business requirements more intimately than they normally would and the Citizen Developer can get exposure to more technical aspects of the implementation that are outside their current technical competency.


Just like conventional Pair programming, the team can be arranged in multiple variations depending on the characteristics of the individuals and the task ahead. The Developer can act as a lead, taking business requirements from the Citizen Developer and then planning out future development steps. The roles could also be reversed with the Citizen Developer acting as the lead. Another methodology would be that the Citizen Developer does most of the development, but a Developer is available as a mentor or to provide support on critical stages of the development process.

I fall into the category of Citizen Developer and was involved in the migration to Azure SQL of a legacy Excel application with an extensive ETL layer based on Power Query and DAX. While I’m a strong Power Query and DAX user, and had an understanding of the inner workings of the Excel application, I was fresh to SQL and SSIS. Translating the logic from the multiple Excel files would have been challenging for a Developer working solo, as the business requirements were not obviously visible within the Excel code. Likewise, the project would have been impossible for me alone, as both SQL and SSIS are far too extensive of applications to learn in a short time frame without guidance. With the help and advice of a Developer the project was successfully completed leading to a near 50x improvement in report refresh time. By the halfway point of the project, the Developer and I could fluently speak on both the business and technical requirements of the project as the Developer understood the business processes, and thanks to their help I could now work with SQL and SSIS. Pair Programming adapted to trained Developer and Citizen Developer provides an opportunity for both individuals to expand their skill sets while generating an efficient and effective solution for the problem at hand.