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.

Practice makes Perfect... thoughts on software testing & professionalism

Which camp are you in? Should we overlook Christina Aguilera's Superbowl faux pas as a moment of human fallibility? Should we strip her of her citizenship and deport her to outer Mongolia for disrespecting the national anthem?

I think the whole affair provides us a good opportunity to reflect on the standards of professionalism. As a friend of mine pointed out, it was an easy mistake to make, could of happened to anybody, she doesn't deserve to be picked to death for it. This is true. On the other hand, in this context she was more than just anybody, she was supposed to be a professional. Being professional means you don't make 'easy' mistakes. It means that when the eyes of a nation are on you, you perform flawlessly, disregarding any but the most unforeseeable events.

Professionals are held to a higher standard. We expect them to practice, to drill, to repeat their performance hundreds of times. We expect them to accept criticism, to seek feedback, and to work out the kinks. As an audience, we don't accept seeing a beta-test on game day.

Which camp are you in?

Do you let project timelines drive shipping untested code to your customers? Do you shrug your shoulders at each new reported bug and say 'well I'm only human'?

Do you use automated testing so that each feature is practiced hundreds of times to work out all the kinks? Do you look at each new bug and ask "How could I have missed that?", and then take action to ensure it can never happen again?

Athletes and performers who "practice, practice, practice" are rewarded by defect free performances. Software developers who "test, test, test" are rewarded by defect free code. In either case, mistakes do and will still happen. But why waste your audience's respect and patience on the easy ones?