Andrew Hunt & Dave Thomas: 
                  The Pragmatic Programmer 
              A comparison with eXtreme Programming 
             
                       Magnus Tingne 
                 D02, Lund Institute of Technology, Sweden 
                     d02mti@student.lth.se 
                           
                        20 feb -07 
             
             
            Abstract This paper is a short comparison between The Pragmatic 
            Programmer by Andrew Hunt & Dave Thomas and the development 
            method eXtreme Programming, eXtreme Programming is the method 
            used in the course where this paper were written.  
                          1
                            1 Introduction 
                                This comparison was performed as a deep-study in the course 
                            “Coachning av programvaruteam (EDA270)”, a voluntary course in 
                            the “Computer Science and Engineering” program on Lund’s Institute 
                            of Technology, Sweden.  
                                It was performed by reading the book while at the same time 
                                                                       1, XP, would advice you to 
                            thinking about how Extreme Programming
                            do the same thing, for example what the view is on Refactoring in 
                            Hunt & Thomas’ book and what the view is in XP. To make sure that 
                            the XP-methodology was relatively fresh in mind some articles from 
                            the course were also read, see the Reference List for details. 
                                The Pragmatic Programmer is centered on short theory parts which 
                            are almost always ended with a Tip, for instance “Tip 1, “Care About 
                            Your Craft””[1]. This comparison will try to use these tips and 
                            compare them to what XP suggests. All tips can be found in Appendix 
                            A. It is important to remember that the book isn’t a complete 
                            development-method like XP but rather a guide to becoming a better 
                            programmer and writing better software. 
                                We will start by going through the main similarities in section 2 by 
                            going through some of XP’s practices and what Hunt & Thomas’s 
                            view is on those. Then I will add some personal notes on the book 
                            annd the tips in section 3. 
                                 
                                 
                            2 Similarities with XP 
                             
                              2.1 Refactoring 
                                         “Tip 4, “Don’t Live with Broken Windows””[1] 
                                According to Hunt & Thomas the main reason why in inner cities 
                            some buildings are beautiful and clean while others are falling apart is 
                            a broken window. If a broken window is left alone for a significant 
                            period of time the tenants in the building stop caring about their house 
                            and the house start falling apart. 
                                This can be applied to code too, if you leave what in XP is called 
                            “a bad smell” in the code for a long period of time other programmers 
                            will stop caring if their code isn’t that good either and the code will 
                            rapidly decline. 
                                                                             
                            1 “Extreme Programming (XP) is a software engineering methodology, the most 
                            prominent of several agile software development methodologies. Like other agile 
                            methodologies, Extreme Programming differs from traditional methodologies 
                            primarily in placing a higher value on adaptability than on predictability.” [6a] 
                                                               2
                                   Hunt & Thomas suggests that bad code should be fixed 
                               immediately if possible, if there isn’t time it should be put on a board, 
                               commented out or just switched for dummy data until it can be 
                               resolved.  
                                   “Tip 47, “Refactor Early, Refactor Often””[1] 
                                   As soon as you find some code that doesn’t feel right, refactor it. If 
                               you refactor immediately you will get around to it but if you wait 
                               maybe there won’t be time for it before the customer wants it to be 
                               shipped. Then the maintenance will be much harder because the code 
                               isn’t as good as it should be. 
                                   Hunt & Thomas has some suggestions on how to do refactoring, 
                               the main points are: 
                                       •   Never refactor and add functionality at the same time. 
                                       •   Have tests that you can run after to be sure you haven’t 
                                           destroyed anything. 
                                       •   If the refactoring is big, do it in small steps. 
                                   All agile methods embrace refactoring because they know that 
                               changes will occur. Bendix & Ekman [3] has refactoring as one of 
                               their main activities in Software Configuration Management. They 
                               also write that it has to be reversible so one can go back if the 
                               refactoring fails. This is also mentioned by Hunt & Thomas as a good 
                               thing and they suggests always using Source Code Control. We will 
                               get back to this in section 2.3 Reversibility. 
                                    
                                                         2 
                                 2.2 Bad smells in code
                                              “Tip 11, “DRY—Don't Repeat Yourself””[1] 
                                   According to Beck & Fowler [6], one of the worst smells you can 
                               have in your code is code duplication. You should never have the same 
                               code in two places. The main reason for this is since we have fast 
                               changing requirements we never know when we need to change the 
                               code. If we have the same code in several places all these has to be 
                               changed, then it’s not a matter of if but more a matter of when 
                               someone will miss to change the code in one of the places. This could 
                               lead to a lot of problems. 
                                   But neither Beck nor Hunt & Thomas stop there. They say that 
                               there should be no duplication at all, in the code or anywhere else. If 
                               for example you have documentation for the code; that should be 
                               generated from the code instead of written separately (see Code and 
                               Tests in [3]). This way when the code changes you won’t have to 
                               change the documentation too. 
                                                                
                                                                               
                               2 “In the community of computer programming, code smell is any symptom that indicates 
                               something may be wrong. It generally indicates that the code should be refactored or the 
                               overall design should be reexamined. The term appears to have been coined by Kent Beck on 
                               WardsWiki. Usage of the term increased after it was featured in Refactoring. Improving the 
                               Design of Existing Code.” [6b] 
                                                                    3
                                  Bad smells in code is closely connected to refactoring since as 
                              soon as you find something that doesn’t seem right, you should 
                              refactor it. 
                                  Comments in the code is often a bad smell according to Beck & 
                              Fowler, if you see a place where the code has a lot of comments it’s 
                              most often because the code isn’t very well implemented. Hunt & 
                              Thomas agrees with this view and says that you should only use 
                              comments in the code to say why and not how. To have a comment 
                              that explains how a thing is implemented is a violation of the DRY-
                              principle. If you change how you implement it you also have to change 
                              the comment. 
                                     “Tip 13, “Eliminate Effects Between Unrelated Things””[1] 
                                  Another bad smell according to Hunt & Thomas is when unrelated 
                              things affect each other. They use an example of flying a helicopter 
                              where moving one lever affects a totally different part. Since we want 
                              our code as simple as possible we don’t want these dependencies. If 
                              we change the code in one place only that part should be affected. 
                                   
                                2.3 Reversibility 
                                             “Tip 14, “There Are No Final Decisions””[1] 
                                  As mentioned earlier it is very important to be able to reverse what 
                              you have done. Most programs have an “Undo” command, but maybe 
                              you don’t find the error that was caused by the change immediately but 
                              instead in a couple of days, what then? 
                                  Another possibility is that you, in the beginning of the project, 
                              decided to use a specific kind of database. But then you get an order 
                              from the customer that you need to use another kind of database. If 
                              you don’t have any reversibility you are in a pickle.  
                                           “Tip 23, “Always Use Source Code Control””[1] 
                                                                                                  3, not 
                                  Hunt & Thomas tells us to always use Source Code Control
                              only when programming. You should even put telephone-lists and 
                              build/release-procedures etc under source code control. This way you 
                              always have a copy of the older versions and can go back if something 
                              goes wrong. Bendix & Ekman agrees with Hunt & Thomas that having 
                              the possibility to recreate an old version of a document is important. In 
                              their article Software Configuration Management in Agile 
                              Development [3] there is a part about Version Control which allows 
                              you to recreate an old version of a document. 
                                                              
                                                                              
                              3 “Revision control (also known as version control, source control or (source) code 
                              management (SCM)) is the management of multiple revisions of the same unit of information. 
                              It is most commonly used in engineering and software development to manage ongoing 
                              development of digital documents like application source code, art resources such as 
                              blueprints or electronic models and other critical information that may be worked on by a team 
                              of people. Changes to these documents are identified by incrementing an associated number or 
                              letter code, termed the "revision number", "revision level", or simply "revision" and associated 
                              historically with the person making the change. A simple form of revision control, for 
                              example, has the initial issue of a drawing assigned the revision number "1". When the first 
                              change is made, the revision number is incremented to "2" and so on.” [6c] 
                                                                  4