{"id":1274,"date":"2021-05-28T16:24:06","date_gmt":"2021-05-28T07:24:06","guid":{"rendered":"http:\/\/blog.box.kr\/?p=1274"},"modified":"2021-05-28T17:25:05","modified_gmt":"2021-05-28T08:25:05","slug":"pair-programming-is-not-pair-coding","status":"publish","type":"post","link":"https:\/\/blog.box.kr\/?p=1274","title":{"rendered":"Pair Programming Is Not Pair Coding"},"content":{"rendered":"\n
from : https:\/\/dzone.com\/articles\/pair-programming-is-not-pair-coding?edition=675393 <\/a><\/h6>\n\n\n\n

The reason pair programming has never been as popular as other agile practices may be that we want to jump straight to coding and design as we go along. That doesn’t work in pairs. Designing in pairs but coding and reviewing on your own is a compromise worth considering.<\/h3>\n\n\n\n

 <\/a>by Jasper Sprengers<\/a>CORE <\/strong>\u00b7 May. 19, 21 \u00b7 Agile Zone<\/a> \u00b7 OpinionLike (5)<\/a><\/p>\n\n\n\n

 Comment (0) Save  Tweet<\/a> 3,750 Views<\/p>\n\n\n\n

Pair programming has a long and respectable history. Frederic ‘<\/em>No Silver Bullet’<\/em> Brooks practiced it as early as 1953<\/a>. It makes Scrum, CI\/CD, and BDD look like recent fads by comparison. I\u2019ve worked in teams where the latter were practiced with a good deal of commitment and success, but pair programming has never been popular. I am not surprised. I must have racked up no more than a week of solid pairing during 22 years as a developer and I wasn\u2019t convinced of the alleged benefits.<\/p>\n\n\n\n

There\u2019s a slightly unsavory intimacy about using the same keyboard, mouse, and monitor that doesn\u2019t work for me at all. I don\u2019t like other people manhandling my keyboard or mouse, pointing their finger at and even against my screen \u2013 the horror! I am picky about my peripherals and often spend my own money on the best quality there is. My development environment is set up just the way I like it, with custom key shortcuts that don\u2019t make sense to anyone but me. It\u2019s not set up for other people\u2019s convenience.<\/p>\n\n\n\n

Now, these physical barriers needn\u2019t be a deal-breaker. You can swap keymaps in your IDE. You can attach two keyboards and mice to your workstation \u2013 and order a bigger desk. Or you can each stay where you are using IntelliJ\u2019s code-with-me plugin and the physical distance doesn\u2019t matter anymore. Yet no physical aid can make the practice any more appealing to me. It\u2019s the mental challenge of working on the same piece of code together. The way we tend to code doesn\u2019t scale well to more than a single brain.<\/p>\n\n\n\n

Coding Is Not Like Peeling Potatoes<\/h2>\n\n\n\n

The school of pair programming tells you to switch roles between writing the code (the driver) and observing\/reflecting on what\u2019s being written (the navigator). They insist on that division not just because using the same mouse and keyboard at the same time is cumbersome. The reason we need to rotate these distinct roles is because of the mental processes of writing code. You can\u2019t coordinate two brains to produce a single line of code in tandem. You can\u2019t divide up the task, therefore it can\u2019t scale. Peeling a sack of potatoes is perfectly scalable: just take half a sack each. Coding is a thought process that must come out through an ancient QWERTY interface until Elon gives us all a brain implant. The typing itself is an overrated skill.<\/p>\n\n\n\n

 Any code I type starts as an extremely \u2018drafty\u2019 version. I arrange and re-arrange my thoughts through the code on my screen. Modern IDEs and strongly typed languages make it a breeze. I don\u2019t have a full mental image of the program in my head that my fingers can just turn into a bug-free executable. I type something and throw it out a minute later when a better alternative pops into my head. I don\u2019t want anyone looking over my shoulder because it\u2019s exhausting to explain myself verbally each step of this rocky road. This can\u2019t be much fun for the other party. They have to sit in forced silence until there\u2019s a piece of working code that they are invited to have an opinion about.<\/p>\n\n\n\n

 It doesn\u2019t have to be like this. After all, it is called pair programming, not pair coding. The two are not the same thing and many others have made the same comment in the context of pair programming. Coding is a vital part of the much broader discipline of programming, which includes specification and design. Yet we tend to equate the two as if coding is all that matters. Why has the development community at large become so dismissive, even scornful, of up-front design? We take a business requirement and jump straight to code, iterating towards an acceptable version and hoping an elegant design emerges as we code. Even when it works, coding like this is doomed to stay a solo exercise for all the reasons I just explained. The older proponents of pair programming very likely came to the table better prepared, with more detailed specifications and designs. Their Emacs wasn\u2019t loaded with all the refactoring goodies we take for granted. The mental process to arrive at working code must have been much more structured and therefore suitable to do in pairs. That makes all the difference.<\/p>\n\n\n\n

 Allow me a little interlude by way of comparison. A stage play consists of dialogue for the actors to interpret, much as lines of code are interpreted by a virtual machine. Writing the dialogue usually takes less than half of the entire writing job, although it is 100% of the finished product. A dramatist develops the plot and character by writing imaginary biographies of people in the play. There is an iceberg of preparation that can take months before you write a single line of dialogue and even then, you go through several revisions of the dialogue. You can always make a phrase more catchy, more emotional, or more informative. The same goes for iterations of writing code. The more up-front design doesn\u2019t mean the first time right. But the changes will be smaller and less sweeping. There are still many ways to Rome, but the journey will have fewer unexpected detours.<\/p>\n\n\n\n

Do We Need Two Pairs of Highly Paid Eyes?<\/h2>\n\n\n\n

Our habit to design by coding may just be the reason why pair programming never caught on. It makes it an unappealing if not impossible option. Yet this straight-to-code approach is a habit you can change. We can gather our thoughts in pseudo-code and free-format diagrams. This works very well in pairs. The results will be a better mutual understanding of the task at hand when you start coding. However, if the two of you have made a sufficiently detailed design of the code-to-be it begs the question of whether it is still worthwhile to have two highly paid pairs of eyes during the actual coding stage, just to avoid implementation errors. I don\u2019t think it\u2019s worth it. In the \u2018olden days\u2019 of waterfall rolling out new versions of code was vastly more expensive compared to a good set-up CD pipeline in a cloud infrastructure. First-time right actually made sense back then. <\/p>\n\n\n\n

 I can do without pair coding. I am not convinced the quality gains outweigh the extra cost, and I am quite sure I don\u2019t need it to feel happier in my job. But I would<\/em> welcome a lot more collaboration in the specification and design stage. There are always requirements to software. The problem is we often don\u2019t make them sufficiently explicit. Figuring them out from source code is exhausting and painful. Fleshing out the requirements, solving ambiguities, eliminating assumptions: all these had better be addressed before coding. The good news is that they are much, much better suited to a pair treatment than coding. A group of three or four will also work fine. This is the stage to ask questions, find answers and get everyone on the same page. This is where you discuss and define your APIs and data\/transfer models because they are more design than implementation. This is where you write your Given\/When\/Then scenarios in plain English for behavior-driven design. The group setting is where you address anything controversial and reach a consensus on the direction to take.<\/p>\n\n\n\n

Design Together, Code, and Review on Your Own<\/h2>\n\n\n\n

Implementation in working code will be quicker and less contentious after that. You have a detailed grasp of the requirement and any serious differences of opinion can be resolved before you start coding. After designing together, the pair or trio parts ways and implements the code on their own. Later they review each other\u2019s work thoroughly, a practice that many teams alreadyfind valuable. An added benefit here is that the reviewer will have been involved in the design of the code, which guarantees better understanding, fewer surprises, and higher quality of this vital review stage.<\/p>\n\n\n\n

I must press one important parting thought. The approach I outlined is not a return to comprehensive up-front design. Design should be detailed, but each design session is concerned with a manageable chunk of work representing no more than a day for each developer. In practice, that means getting together every day for an hour to 90 minutes and basically create software without writing code. I have tried it, and it works. Please don\u2019t treat it as a meeting. It is actual work and can be really fun too.<\/p>\n","protected":false},"excerpt":{"rendered":"

from : https:\/\/dzone.com\/articles\/pair-programming-is-not-pair-coding?edition=675393 The reason pair programming has never been as popular as other agile practices may be that we want to jump straight to coding and design as we go along. That doesn’t work in pairs. Designing in pairs but coding and reviewing on your own is a compromise worth considering.  by Jasper SprengersCORE \u00b7 May. 19, 21 \u00b7 Agile Zone \u00b7 OpinionLike (5)  Comment (0) Save  Tweet 3,750 Views Pair programming has a long and respectable history. Frederic ‘No Silver Bullet’ Brooks practiced it as early as 1953. It makes Scrum, CI\/CD, and BDD look like recent fads by comparison. I\u2019ve worked in teams where the latter were practiced with a good deal of commitment and success, but pair programming has never been popular. I am not surprised. I must have racked up no more than a week of solid pairing during 22 years as a developer and I wasn\u2019t convinced of the alleged benefits. There\u2019s a slightly unsavory intimacy about using the same keyboard, mouse, and monitor that doesn\u2019t work for me at all. I don\u2019t like other people manhandling my keyboard or mouse, pointing their finger at and even against my screen \u2013 the horror! I am picky about my peripherals and often spend my own money on the best quality […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"ngg_post_thumbnail":0,"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[5],"tags":[],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5q9Zn-ky","jetpack-related-posts":[{"id":178,"url":"https:\/\/blog.box.kr\/?p=178","url_meta":{"origin":1274,"position":0},"title":"std::map example","date":"2014-07-09","format":false,"excerpt":"\/\/ std::map example \/\/ opposite words #include #include #include using namespace std; typedef std::map TStrStrMap; typedef std::pair TStrStrPair; int main(int argc, char *argv[]) { TStrStrMap tMap; tMap.insert(TStrStrPair(\"yes\", \"no\")); tMap.insert(TStrStrPair(\"up\", \"down\")); tMap.insert(TStrStrPair(\"left\", \"right\")); tMap.insert(TStrStrPair(\"good\", \"bad\")); std::string s; std::cout << \"Enter word: \" << std::endl;; std::cin >>\u2026","rel":"","context":"In "C\/C++"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":321,"url":"https:\/\/blog.box.kr\/?p=321","url_meta":{"origin":1274,"position":1},"title":"MFC] – CWebBrowser2 \uc5d0\uc11c IWebBrowser2 \uc0ac\uc6a9\ud558\uae30","date":"2014-08-09","format":false,"excerpt":"\ucc38\uace0 :\u00a0http:\/\/computer-programming-forum.com\/82-mfc\/20b17af03936f1e8.htm You can get the IWebBrowser2 from the CWebBrowser2 something like this... \u00a0 \u00a0 IWebBrowser2* GetIWebBrowser2FromCWebBrowser2(CWebBrowser2& wndBrowser) { IWebBrowser2* piWebBrowser2=NULL; if (LPUNKNOWN pUnk = wndBrowser.GetControlUnknown()) { if (SUCCEEDED(pUnk->QueryInterface( IID_IWebBrowser2, (void**)&piWebBrowser2))) { \/\/ Remember to call Release return piWebBrowser2; } } return NULL; } And call it something like this...\u2026","rel":"","context":"In "C\/C++"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":371,"url":"https:\/\/blog.box.kr\/?p=371","url_meta":{"origin":1274,"position":2},"title":"Clojure vs Scala","date":"2014-09-15","format":false,"excerpt":"http:\/\/programming-puzzler.blogspot.kr\/2013\/12\/clojure-vs-scala.html Clojure vs Scala Last week, someone posted a question on the Clojure group asking for a comparison between Clojure and Scala. Since my most popular blog post, by far, is my\u00a0Racket vs Clojure\u00a0post from three years ago, I thought it would be good to post my response here.Ten years\u2026","rel":"","context":"In "\ucc38\uace0\ub97c \uc704\ud55c \uc800\uc7a5\ubb3c"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":395,"url":"https:\/\/blog.box.kr\/?p=395","url_meta":{"origin":1274,"position":3},"title":"[\ud38c][\uc601\uc0c1\ucc98\ub9ac] Visual Studio 2010 + OpenCV 2.4.8 \uc124\uce58","date":"2014-09-15","format":false,"excerpt":"http:\/\/dsnight.tistory.com\/1 \u00a0 http:\/\/docs.opencv.org\/2.4.8\/doc\/user_guide\/ug_mat.html#input-output Visual Studio 2010\uc5d0 OpenCV 2.4.8\ubc84\uc804\uc744 \uc124\uce58\ud574 \ubcf4\uaca0\ub2e4. Visual 6.0 + OpenCV 1.0 \ubc84\uc804\ubd80\ud130 Visual Studio2012\uae4c\uc9c0 OpenCV\ub97c \uc124\uce58\ud574 \ubcf4\uc558\uc9c0\ub9cc OpenCV\ub97c \uc124\uce58\ud558\ub294 \uc77c\uc774\ub780 \ucc38 \uadc0\ucc2e\ub2e4.. \uc774\ubc88\uc5d4 Visual Studio 2010\uc5d0 \uc124\uce58\ub97c \ud560\ud150\ub370, Visual Studio 2012\uc5d0 \uc124\uce58\ud558\ub294 \ubc29\ubc95\uc774\ub791 \ubcc4 \ub2e4\ub978 \ucc28\uc774\ub294 \uc5c6\uc744\ub4ef \ud558\ub2e4. 1. OpenCV \ub2e4\uc6b4\ubc1b\uae30 \ub2e4\uc6b4\ubc1b\uc73c\ub7ec \uac00\uae30 \uc124\uce58\ud558\uae30 \uc704\ud574 OpenCV\u2026","rel":"","context":"In "\ucc38\uace0\ub97c \uc704\ud55c \uc800\uc7a5\ubb3c"","img":{"alt_text":"","src":"http:\/\/cfile28.uf.tistory.com\/image\/2523004252C94E100BB207","width":350,"height":200},"classes":[]},{"id":724,"url":"https:\/\/blog.box.kr\/?p=724","url_meta":{"origin":1274,"position":4},"title":"[\ud38c]45 Useful JavaScript Tips, Tricks and Best Practices","date":"2015-04-15","format":false,"excerpt":"http:\/\/modernweb.com\/2013\/12\/23\/45-useful-javascript-tips-tricks-and-best-practices\/ \u00a0 45 Useful JavaScript Tips, Tricks and Best Practices By Saad Mousliki As you know, JavaScript is the number one programming language in the world, the language of the web, of mobile hybrid apps (like PhoneGap or Appcelerator), of the server side (like NodeJS orWakanda) and has many other\u2026","rel":"","context":"In "JAVA"","img":{"alt_text":"keep-calm-and-learn-javascript","src":"https:\/\/i0.wp.com\/fw008950-flywheel.netdna-ssl.com\/wp-content\/uploads\/2013\/12\/keep-calm-and-learn-javascript.jpg?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":698,"url":"https:\/\/blog.box.kr\/?p=698","url_meta":{"origin":1274,"position":5},"title":"Securing Svnserve using SSH","date":"2015-04-15","format":false,"excerpt":"http:\/\/tortoisesvn.net\/ssh_howto.html Securing Svnserve using SSH This section provides a step-by-step guide to setting up Subversion and TortoiseSVN to use the svn+ssh protocol. If you already use authenticated SSH connections to login to your server, then you are already there and you can find more detail in the Subversion book. If\u2026","rel":"","context":"In "\uae30\uc220\uc790\ub8cc"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/posts\/1274"}],"collection":[{"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.box.kr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1274"}],"version-history":[{"count":1,"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/posts\/1274\/revisions"}],"predecessor-version":[{"id":1275,"href":"https:\/\/blog.box.kr\/index.php?rest_route=\/wp\/v2\/posts\/1274\/revisions\/1275"}],"wp:attachment":[{"href":"https:\/\/blog.box.kr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.box.kr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.box.kr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}