{"id":153,"date":"2006-03-03T09:52:20","date_gmt":"2006-03-03T09:52:20","guid":{"rendered":"http:\/\/kubasek.com\/blog\/pragmatic_craftsman\/?p=153"},"modified":"2006-03-03T09:52:20","modified_gmt":"2006-03-03T09:52:20","slug":"good-xp-practices","status":"publish","type":"post","link":"https:\/\/pragmaticcraftsman.kubasek.com\/2006\/03\/03\/good-xp-practices\/","title":{"rendered":"Good XP Practices"},"content":{"rendered":"<p>Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don&#8217;t think I could withstand all of the practices on a continual basis. Having to pair program on a continual basis is just a pain (bathroom, personal calls, taking breaks, etc). I think it could be done at times, for instance, fixing a critical issue, but on a day to day basis, I dont&#8217; think I would  be able to do it.<\/p>\n<p>Here are the practices of XP, taken from <em>Extreme Programming Explained<\/em> book, which I&#8217;m currently reading.<\/p>\n<ul>\n<li><em>The Planning Game<\/em> &#8212; Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.<\/li>\n<li><em>Small releases<\/em> &#8212; Put a simple system into production quickly, then release new versions on a very short cycle.<\/li>\n<li><em>Metaphor<\/em> &#8212; Guide all development with a simple shared story of how the whole system works.<\/li>\n<li><em>Simple design<\/em> &#8212; The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.<\/li>\n<li><em>Testing<\/em> &#8212; Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.<\/li>\n<li><em>Refactoring<\/em> &#8212; Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.<\/li>\n<li><em>Pair programming<\/em> &#8212; All production code is written with two programmers at one machine.<\/li>\n<li><em>Collective ownership<\/em> &#8212; Anyone can change any code anywhere in the system at any time.<\/li>\n<li><em>Continuous integration<\/em> &#8212; Integrate and build the system many times a day, every time a task is completed.<\/li>\n<li><em>40 hour week<\/em> &#8212; Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.<\/li>\n<li><em>On-site customer<\/em> &#8212; Include a real, live user on the team, available full-time to answer questions.<\/li>\n<li><em>Coding standards<\/em> &#8212; Programmers write all code in accordance with rules emphasizing communication through the code.<\/li>\n<\/ul>\n<p>Based on these practices, I think a good agile process should have the following practices (from the XP process).<\/p>\n<ul>\n<li><strong>Small releases<\/strong>. A small release lets you find problems quickly and correct them right away. <\/li>\n<li><strong>Simple design.<\/strong> There is no point on spending too much time designing for the future; nonetheless, some time should be spent on creating a good design, as a bad one can kill or seriously slow down development. No you cannot really refactor a bad design, you would have to rewrite it.<\/li>\n<li><strong>Testing and Refactoring.<\/strong> We all say we do it, but I think we should be doing more of it. This is essential.<\/li>\n<li><strong>Continuous integration.<\/strong> It&#8217;s critical, as a lot of problems are exposed by integrating. <\/li>\n<li><strong>40-hour week.<\/strong> This is very important. I don&#8217;t know about you, but I&#8217;m tired after work. I noticed that when I stay overtime from time to time, I enbug the system. Really.  I put a lot more bugs into the system than normal. Plus, programmers have a life (we do).<\/li>\n<\/ul>\n<p>All in all, XP brought a lot of good practices to the development world. It was, and still is, a disruptive force. And that&#8217;s a good thing. Whatever your process is, make sure it is agile, and exposes problems early.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don&#8217;t think I could withstand all of the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-153","post","type-post","status-publish","format-standard","hentry","category-software-engineering"],"_links":{"self":[{"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":0,"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"wp:attachment":[{"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pragmaticcraftsman.kubasek.com\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}