Remember, pen and paper are your best friends. Some A4 paper, post-it notes, and sharpies.If applicable, you might want dual screens.Īpart from that, here are a few more items you’ll need: So it won't last long if you’re uncomfortable.īefore you start coding, make sure the screen is at an optimal height and adjust the height of your seat to make it suitable for you and your peer. If you have been staring at the monitor for too long with a poor posture, the pain will distract you from the coding, and you will find it more difficult to focus. This is neglected by most beginners however, this is a fundamental step that can determine whether the practice is sustainable or not. Just before you start typing any fancy code, you should set up the environment first.įirstly, you will need an external monitor and a height-adjustable table (ever tried making a DIY one with cardboard boxes?). Let’s assume that you have already found your peer, and cannot wait to get started with a particular user story. It has a lot of principles to follow, and if only the devs in a team can apply those principles correctly, can they benefit from it. Of course, pair programming is not just about two devs sitting together and writing code in turn - it's a science and a fun-filled (well, almost) engineering practice. This article is for those who have already decided as a team to give it a try and are wondering how to do it, or for those who found that it is not as practical as it sounds, and want some useful guidance. I'm not going to discuss how the pair programming affects productivity, or whether you should adopt it in your next project, or to what extent you should apply it in your own project. Frankly, doing pair programming is the most challenging part of almost all of the projects I've worked on. And for some organizations, it's crucial to measure everything. They argue that it is difficult for developers to focus on the delivery task when working in pairs and that the devs will most likely end up debating over trivial things like 'deciding which text editor to choose.'Īdditionally, another common issue is that it is challenging to measure performance for each developer when a team adopts pair programming. For the rest, even if they claim they are doing agile, they will often be divided into two camps.įirst, there are the advocates who support pair programming by arguing that it leads to knowledge transfer, reduction in potential defects as well as the removal of 'information islands.' The opponents, however, believe it is a waste of time. In fact, only a few teams that adopt it can actually benefit from it. It is a relatively controversial practice among all of the agile methods, if not the most. Pair programming is an agile software development technique in which two programmers work together at one workstation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |