Business Analogy for Pair Programming

In the Atlanta Craftsmanship meetup this past Monday we discussed TDD and pair programming followed by a live practice of the ping-pong technique.   What was interesting is how many of the side conversations  involved folks struggling to gain management acceptance for these techniques.   It just seems to fly in the face of common sense to have two resources as expensive as developers working on the same problem.

I think I'm going to try a new conversation with my management and  use some tried and true management advice from Deming in support of paired programming vs traditional silos of development.

I found David Joyce's post Deming’s 14 Points to be a good source of new arguments:

Point 3:  Cease dependence on mass inspection.
Eliminate the dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

Longer cycles of QA, formal code reviews, static code tools:  even if these methods of inspection could find every bug in every release,  they will always find them too late.  Top late when compared to cost to fix a problem right after it is created..   Beyond that Pair programming validates more than just the basic implementation,  you're discussing the assumptions, the risks, the benefits of the choices being made.

Point 6. Institute training on the job:
Institute modern methods of training on the job.

Deming recommends training by doing.  Pair programming keeps knowledge flowing among all team members.  Nobody becomes a sole expert on any part of the code and the best tools can be vetted and adopted quickly.

8. Drive out fear:
Drive out fear so that everyone may work effectively for the company.

Techies fear being wrong, fear ridicule from their peers.  Paring means talking, talking builds trust, trust eliminates fear.  Without fearing what your co-workers think,  you have freedom to disagree, freedom to experiment, and freedom to innovate.

9. Break down barriers:
Break down barriers between departments. People in research, design, sales, technology and production must work as a team.

Pairing is all about seeing a problem from more than one perspective.  Becoming comfortable with different opinions and interpretations between peers builds the very same skills that support communication with the business.   

13. Encourage education:
Institute a vigorous programme of education and self-improvement.

Let's be honest, a good programmer could not care less about what their 'manager' thinks of their skills. The validation that matters comes from their peers.  Pairing provides consistent and immediate reward for your continued learning,  every day you get to impress somebody else with the knowledge you've picked up.

Technical Debt Analogy - Paying the Gremlin Bond?

Ward Cunningham's 'Technical Debt' discussion is a favorite metaphor to help the business relate why not all IT spending can be on new features. However, after a crazy semi-annual install, I find that perhaps there needs to be an extension to the metaphor, the Gremlin Bond.

Homeowners in the South are familiar with a form of insurance known as a Termite Bond. We pay an exterminator to regularly apply pesticides and bait traps around our homes to ward off infestation.  To wait until you see evidence of termite damage is insanity.  At the point you know the termites are there, you might as well start shopping for a new house.

Code gremlins also quietly accumulate, often asymptomatically, until it's too late to remedy things without going to scorched earth and rebuilding from scratch.  Time spent writing automated tests, refactoring, code reviews, and upgrading system components is the Gremlin Bond.  Less sexy than building a new house every couple of years,  but far more predictable and therefore manageable cost over time.