What you don't know about XP will hurt you
Just like what you don't know about sniping without an observer can kill you. Maybe that is the most appropriate analogy, Sniper/Observer pairing, in XP, it can be coder/observer pairing. Like an observer in a sniper duty, he/she is not only focused on the target at sight, he/she has to observe the surroundings ask questions like "is our position compromised?", "did the enemy spotted us?". He/she also has to provide cover for the sniper when things goes awfully wrong.
In XP's pair programming, almost an equivalent scenario applies. Observers does not only watch the coder type away. The observer has to consider how that particular piece of code currently being written will affect the whole application, is the code style correct? Are the use of patterns correct? Are the singletons should be where they are? Will it become a bottleneck if we integrate with X Team's API? In a looming deadline, the observer can also sit down side by side with the coder, he/she can build some urgent test cases, prototype user interfaces while the coder continue writing the business modules and data objects needed(this is like providing cover fire).
Just like in combat, snipers/observers are not the only elements/operators you need to win the war. They only make fighting easier, "safer" and faster for the regular infantry. And their utilization is "as-per-needed" basis only. No general will order a full regiment of snipers/observers to the front, that's ridiculous. Only missions that requires speed and clean extraction such resource will be employed, and will come out as if nothing happened.
That's what corporate developers find difficult to swallow, the "as if nothing happened" part. Most of them always needs recognition for every efforts, individual recognitions. And XP efforts are one of the most difficult to appraise especially in a traditional brick-and-mortar company.But pair programming isn't the silver bullet in every SDLC, just like snipers/observers they're used in special situations anywhere in the SDLC phase.
In XP's pair programming, almost an equivalent scenario applies. Observers does not only watch the coder type away. The observer has to consider how that particular piece of code currently being written will affect the whole application, is the code style correct? Are the use of patterns correct? Are the singletons should be where they are? Will it become a bottleneck if we integrate with X Team's API? In a looming deadline, the observer can also sit down side by side with the coder, he/she can build some urgent test cases, prototype user interfaces while the coder continue writing the business modules and data objects needed(this is like providing cover fire).
Just like in combat, snipers/observers are not the only elements/operators you need to win the war. They only make fighting easier, "safer" and faster for the regular infantry. And their utilization is "as-per-needed" basis only. No general will order a full regiment of snipers/observers to the front, that's ridiculous. Only missions that requires speed and clean extraction such resource will be employed, and will come out as if nothing happened.
That's what corporate developers find difficult to swallow, the "as if nothing happened" part. Most of them always needs recognition for every efforts, individual recognitions. And XP efforts are one of the most difficult to appraise especially in a traditional brick-and-mortar company.But pair programming isn't the silver bullet in every SDLC, just like snipers/observers they're used in special situations anywhere in the SDLC phase.
Comments
not tried XP yet. might not even dare to do so.
why i am afraid of xp
As a leader, personal behaviour is a not part of XP's equation, that is beyond XP's scope. There will be disagreements, but of course, arguments should be for the interest of the completion of the project.
Yes, I do like XP and I know when to use it.