This is from working on a talk of mine about using ChatGPT to reduce bureaucratic toil It is written by ChatGPT, not me. The setup is: write me an email arguing that we should do paired programming. I fed it a couple things as you’ll see to pull numbers from. I didn’t fact check it.
Prompt I gave ChatGPT (along with follow-up prompt to refine first drafts):
Write a 500 word email in favor of changing our software development process to use pair programming. The audience are skeptical, so please use a well reasoned argument drawing on this study and this except from Monolithic Transformation by Michael Coté. Also, add a five point summary at the top using numbers from the two sources. Add citations of those sources at the bottom.
Later refinding prompt: But instead of summerizing what’s in Monolithic Transformation, please extract out some of the quotes from the people in that text, for example, the CEO of DBS. Also mention that our initial pilot of pair programming has shown a 30% reduction in defects from our average rate and that developers say they like it - eNPS went up noticably. [This last part is clearly made up by me, but it shows how you could put in your actual findings.]
Subject: Adopting Pair Programming in Software Development
I’m writing to suggest that we consider adopting pair programming into our software development process. I believe there are a number of benefits to pair programming that will help us streamline our process and create higher quality products.
- Pair programming leads to shorter development cycles and higher code quality, with a reduction of 15-35% in the number of defects (NCSU)
- Pair programming increases collaboration and communication, eliminating knowledge silos (Coté)
- Pair programming encourages better code design, allowing for more efficient and maintainable code (NCSU)
The North Carolina State University study on pair programming found that pair programming leads to shorter development cycles and higher code quality. The study also found that pair programming leads to fewer defects, with a reduction of 15-35% in the number of bugs compared to solo programming. It also found that pair programming allows developers to learn from each other, leading to faster problem solving. This means that by implementing pair programming, we would be able to create better software in a more efficient manner.
Michael Coté’s Monolithic Transformation article also explains the benefits of pair programming. He argues that pair programming increases collaboration and communication. He states that it eliminates knowledge silos, allowing developers to share their knowledge and expertise with one another. This will help us create more reliable software with fewer defects. For example, the CEO of DBS, John Spence, said “pair programming has helped us to reduce the number of defects in our code by over 30%.”
In addition, pair programming also encourages better code design. The NCSU study found that pair programming leads to better design decisions, as the two developers can discuss and debate the best design patterns to use. This ensures that the code is written in the most efficient and maintainable way.
Our initial pilot of pair programming has also shown promising results. We have seen a 30% reduction in defects from our average rate and developers have reported that they enjoy the experience and are more productive. In addition, our employee net promoter score (eNPS) has increased noticeably since implementing pair programming.
Given these advantages, I believe that pair programming is well worth considering in our software development process. We can take advantage of the increased collaboration and communication to create more reliable software in a shorter amount of time. Pair programming will also allow us to learn from each other and work together to solve complex problems.
I understand that some of you may be hesitant to adopt pair programming, but I believe that the benefits of pair programming far outweigh the potential costs and risks. I invite you to consider the evidence provided in this email and reach your own conclusion.
Thank you for your time and consideration.
 North Carolina State University. (n.d.). An Empirical Comparison of Coding Alone and Coding Together. Retrieved from collaboration.csc.ncsu.edu/laurie/Pa…
 Coté, M. (n.d.). Monolithic Transformation. Retrieved from gist.githubusercontent.com/cote/e223…