Effective Collaborative Programming3

1,298 views

Published on

This was presented by Amit Sharma and Abhishek Agrawal at Agile NCR 2009 Conference held on 18th July at Park Premier Hotel.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,298
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
39
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The two programmers are still doing two programmers' worth of work, they're just doing it together rather than individually. There's an implicit assumption there that all bugs take the same amount of time to fix. In my experience, this is very much false. When I program without unit tests or a "smart" (syntax-checking) editor, the distribution usually looks like this: 4 hours to write the code. About 6-12 bugs that can be fixed in under 10 minutes. Syntax errors, type mismatches, nulls, and general brain farts. About 2 bugs that take an hour each 1 bug that takes 8-10 hours. which is that
  • Pair programming transforms what has traditionally been a solitary activity into a cooperative effort. Remote pair programming , also known as virtual pair programming or distributed pair programming, is the practice of pair programming where the two programmers comprising the pair are in different locations, working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE plugin.
  • Productivity and quality with distributed teams.
  • A primary consideration in virtual teaming is that of communication. Poor communication can cause problems like inadequate project visibility, wherein everyone does his/her individual work, but no one knows if the pieces can be integrated into a complete solution. Coordination among the team members could also be a problem. Finally, the technology used must be robust enough to support distributed development of software, not just to provide communications.
  • New extension of team (although we very strongly recommend collocation in initial phases)‏
  • The two programmers are still doing two programmers' worth of work, they're just doing it together rather than individually. There's an implicit assumption there that all bugs take the same amount of time to fix. In my experience, this is very much false. When I program without unit tests or a "smart" (syntax-checking) editor, the distribution usually looks like this: 4 hours to write the code. About 6-12 bugs that can be fixed in under 10 minutes. Syntax errors, type mismatches, nulls, and general brain farts. About 2 bugs that take an hour each 1 bug that takes 8-10 hours. which is that
  • Effective Collaborative Programming3

    1. 1. Agile NCR 2009 July 18, 2009 Effective Agile Software Development with Collaborative Programming
    2. 2. Agenda <ul><li>What is Collaborative Programming? </li></ul><ul><li>A day in solo programming </li></ul><ul><li>A day in pair programming </li></ul><ul><li>Economics of collaborative programming </li></ul><ul><li>Cultural and psychological challenges </li></ul><ul><li>How to do it? </li></ul><ul><li>When not to do it? </li></ul><ul><li>Distributed pair programming </li></ul><ul><ul><li>Need </li></ul></ul><ul><ul><li>What it takes </li></ul></ul><ul><ul><li>Tools </li></ul></ul><ul><ul><li>Demo </li></ul></ul><ul><ul><li>When to do it and when not </li></ul></ul><ul><li>Questions </li></ul>
    3. 3. Collaborative programming <ul><li>Involves two programmers side-by-side on the design, coding and testing of a piece of software. </li></ul><ul><li>The concept of driver and navigator </li></ul><ul><li>Constant active review, knowledge sharing and design discussions </li></ul><ul><li>Pair programming transforms what has traditionally been a solitary activity into an interactive & cooperative effort. </li></ul>
    4. 4. A day of a solo programmer
    5. 5. Challenges of solo programming <ul><li>Focus Factor </li></ul><ul><li>Syntactical errors causing at least 10% loss in productivity </li></ul><ul><li>Passive reviews </li></ul><ul><li>No knowledge sharing </li></ul>
    6. 6. A day in collaborative programming
    7. 7. A day in collaborative programming
    8. 8. A day in collaborative programming <ul><li>Minimal distractions as pairing requires respect for each other. </li></ul><ul><li>Navigator catches the syntactical errors even before you compile the code. </li></ul><ul><li>You find an ACTIVE reviewer. </li></ul><ul><li>Knowledge sharing in its true form. </li></ul><ul><li>Design quality </li></ul>
    9. 9. Economics of pair programming <ul><li>Why should I invest for two programmers for the same task??? </li></ul><ul><li>For any two programmers, no matter how good he or she is, if we get them to sit together, the value of their work will be greater than if they sit apart. </li></ul>
    10. 10. Cultural and psychological challenges <ul><li>Some people prefer working alone </li></ul><ul><li>Move from Waterfall to Agile world (no heroics anymore)‏ </li></ul><ul><li>Egos and personality conflicts </li></ul><ul><li>Intimidation by expert </li></ul>
    11. 11. How to do it? <ul><li>Agree on one tiny goal at a time </li></ul><ul><li>Rely on your partner, support your partner. </li></ul><ul><li>Talk a lot </li></ul><ul><li>Switch roles often </li></ul><ul><li>Write unit test first </li></ul><ul><li>Pay attention – don’t check your email, digg etc </li></ul><ul><li>The person who knows less about the system or language should do most of the driving, to ensure that the novice stays engaged. You learn more through your fingers than through your eyes. </li></ul><ul><li>Ping-pong pairing </li></ul>
    12. 12. When not to do it? <ul><li>When reading about a library that might help later on </li></ul><ul><li>Spiking a complex solution or debugging a tricky error with someone that has an experience gap. </li></ul><ul><li>The number of tasks that require pairing is a lot higher than the number of tasks that don't. </li></ul>
    13. 13. Distributed pair programming
    14. 14. <ul><li>The Need </li></ul><ul><li>Nothing is as effective as collocated team and pair programming. However when teams ARE distributed, we attempt to reach the same level of productivity as for collocated teams - Welcome to the world of Distributed Pair Programming. </li></ul><ul><li>Trivia </li></ul><ul><li>Department of Computer Science, North Carolina State University conducted an experiment to compare the different working arrangements of student teams developing object-oriented software. The results of the experiment indicate that it is feasible to develop software using distributed pair programming, and that the resulting software is comparable to software developed in collocated teams. </li></ul><ul><li>The University's technique is based on the emerging software engineering methodology – “pair-programming” combined with nearly 20 years of widespread and active research in collaborative software systems. </li></ul>Distributed pair programming
    15. 15. <ul><li>What it takes? </li></ul><ul><li>Lots and lots and lots of communication. </li></ul><ul><li>Hardware Challenges </li></ul><ul><li>Software Challenges </li></ul><ul><li>Network Challenges, pair switching </li></ul><ul><li>Cultural Challenges </li></ul><ul><li>Time Differences </li></ul>Distributed pair programming
    16. 16. <ul><li>Tools </li></ul><ul><li>Microsoft Office Communicator (OCS)‏ </li></ul><ul><li>Skype Mikogo </li></ul><ul><li>Cola Eclipse plugin </li></ul><ul><li>Adobe Acrobat Connect </li></ul><ul><li>NetMeeting </li></ul><ul><li>VNC </li></ul><ul><li>XPairtise - A Distributed Pair Programming Plug-in For Eclipse </li></ul><ul><li>Sangam – A Distributed Pair Programming Plug-in for Eclipse - Department of Computer Science, North Carolina State University </li></ul><ul><li>PCAnywhere </li></ul><ul><li>SelfLanguage </li></ul><ul><li>SqueakSmalltalk - has a shared desktop component named Nebraska </li></ul><ul><li>RemoteAdmin from Famatech -- far faster than VNC and far cheaper than PCAnywhere </li></ul><ul><li>SpeakFreely - win32/linux voice chat </li></ul><ul><li>Messengers </li></ul><ul><li>Baseline : Follow KISS principles - high quality cam, mic, headphones </li></ul>Distributed pair programming
    17. 17. <ul><li>Tools </li></ul><ul><li>Experiments by some universities – </li></ul><ul><li>( Carolina State University, University of California et al )‏ </li></ul><ul><li>Virtual WorkSpace was intended as an environment to enable distributed collaboration over a network. It depends heavily on computer-generated graphics and virtual reality devices as well. </li></ul><ul><li>ClearBoard was similarly a non-co-located collaboration support system that allowed two users to appear to sit face to face, and see the shared work between them </li></ul><ul><li>The members of a pair viewed a common PC display using desktop sharing software; They trailed Microsoft NetMeeting, Symantec’s PCAnywhere, and VNC. They used headsets and microphones to speak to each other, and text chat for communications as well. They used several instant messaging programs (Yahoo Messenger, PalTalk, AOL Messenger) before implementing the project. The final experiment was run with NetMeeting , as this program provided PC sharing, text, audio, and video in one platform. </li></ul>Distributed pair programming
    18. 18. <ul><li>Time for some action… </li></ul><ul><li>COLA Eclipse Plugin Demo </li></ul>Distributed pair programming
    19. 19. <ul><li>Opportunities for Distributed Pair Programming </li></ul><ul><ul><li>New extension of team </li></ul></ul><ul><ul><li>KT phases </li></ul></ul><ul><ul><li>Domain expert on either side </li></ul></ul><ul><ul><li>User story specific need </li></ul></ul><ul><ul><li>Collective Code Ownership & knowledge sharing </li></ul></ul><ul><li>When can it be an overkill? </li></ul><ul><ul><li>Mixing Remote and local pairing, long tasks </li></ul></ul><ul><ul><li>When collocated pairing can be done, avoid distributed pair programming. </li></ul></ul>Distributed pair programming
    20. 20. Questions

    ×