Extreme Programming Considered Harmful for Reliable Software Development
Total Page:16
File Type:pdf, Size:1020Kb
AVOCA GmbH Extreme Programming Considered Harmful for Reliable Software Development Status: Approved Author(s): Gerold Keefer Version: 1.0 Last change: 06.02.02 21:17 Project phase: Implementation Document file name: ExtremeProgramming.doc Approval Authority: Gerold Keefer Distribution: Public Security Classification: None Number of pages: 1 Extreme Programming Considered Harmful for Reliable Software Development AVOCA GmbH 1 MOTIVATION ................................................................................................................................... 3 2BIAS................................................................................................................................................. 4 3 BENEFITS ........................................................................................................................................ 4 4 DUBIOUS VALUES AND PRACTICES........................................................................................... 5 5 C3 REVISITED ................................................................................................................................. 7 6 MISSING ANSWERS ....................................................................................................................... 7 7 ALTERNATIVES .............................................................................................................................. 8 8 CONCLUSIONS ............................................................................................................................. 10 9 ACKNOWLEDGEMENTS .............................................................................................................. 10 10 REFERENCES............................................................................................................................ 11 11 ADDITIONAL INFORMATION ON REFERENCES ................................................................... 13 12 CONTACT DATA........................................................................................................................ 14 2002 AVOCA GmbH Page 2 of 14 Extreme Programming Considered Harmful for Reliable Software Development AVOCA GmbH Ein unbegreiflich Licht erfüllt den ganzen Kreis der Erden. Es schallet kräftig fort und fort. Ein höchst erwünscht Verheißungswort. Wer glaubt, soll selig werden. Aria, BWV 125 1 Motivation Following my positive experience with software development in a large telecommunication software project whereby I inspected and unit tested the code of my partner and vice versa, I came across websites that recommended programming in pairs as a practice of a software development method called “Extreme Programming”. I thought this practice to be about the same what we did in that project and recommended it to others. It was about three years later that I became hired as the quality manager of a project that involved around thirty developers and was one of several subprojects of a large SAP migration. On this project one contractor team consisting of about seven programmers intended to develop a Java framework that others would use in the Extreme Programming fashion. At that time I was unbiased towards Extreme Programming, because I simply did not know much about it. What I did know was that a project of that size required substantial planning, analysis, and architectural groundwork up front. This conflicted with the view of that team, which lead to ongoing debates. The chief architect and I clearly favoured the software engineering approach and the customers project leader stood somewhere in the middle, he saw advantages in knowledge transfer to his staff when using pair programming. During the risks analysis that I conducted, conflicting software development philosophies were consequently identified as the topmost risk. In general, we experienced a very slow progress from this team during the development of an architectural prototype. Eventually their leader had to confess that they would not be able to deliver the required work products and apologized for the wasted time and resources. Initially it took an application based on the framework around 40 minutes start up and the memory consumption was unacceptable, clearly exceeding the most moderate performance and resource constraints we had. During the last two years I noticed an ever-growing influence of Extreme Programming on mainstream software development, due to its increasing popularity. This popularity was fuelled by support from respected people like Tom DeMarco and recurrent claims that put Extreme Programming to the level of alchemy, such as one article reporting on an organization employing Extreme Programming that moved from CMM Level 1 to CMM Level 4 within 5 months [Griffin01CMMLevel4]. Everyone was reading Extreme Programming books, Extreme Programming became a widespread conference topic and as I approached the local university campus the first questions I heard was: ”Extreme Programming is great – isn’t it?”. Later on I became involved in many heated debates in Usenet newsgroups, most notably comp.software.extreme-programming, about the validity of the claims and practices of Extreme Programming and investigated deeper. Quite soon I learned that most of them were based on rather thin grounds. My motivation for writing this paper is to put together the information and references I have about the facts of Extreme Programming and how they relate to traditional Software Engineering practices. I will state reasons, albeit no scientific proofs, why I consider Extreme Programming to be harmful for reliable software development and why it provides not many answers to the significant questions that contemporary software development methods have to answer. Secondly, the Extreme Programming hype and its variant in the “Agile Methods” packaging is so dominant, that even if we wanted to ignoring it is no longer an option: My company will give tutorials on “Agile Methods”, because I consider the SCRUM-Method as recommendable. As you can see from the reference section, the practices of Extreme Programming have been explained in many publications. In this paper I will not focus on iterating them. I will directly address the harm as well as the benefit I see accompanying the method. 2002 AVOCA GmbH Page 3 of 14 Extreme Programming Considered Harmful for Reliable Software Development AVOCA GmbH 2 Bias Everyone who followed my comments and thoughts on the Extreme Programming newsgroup will see that I have my opinion about major aspects of Extreme Programming firmly set. In other words I am biased. I consider if appropriate to define my bias before we move further. My degree is in telecommunication engineering and I clearly favour an engineering approach to software development. During the past 5 years I was mainly involved in quality assurance and testing consulting tasks with my company. I moved into the quality assurance direction shortly after experiencing all the pitfalls of a non-quality oriented development environment: • Reliance on verbal communication. • Intuition-based decision making. • High dependency on individual skills. • Insufficient planning. • No sound approach to system verification and validation. Those practices lead to • rework as a norm, • error prone systems, • non-maintainable systems, • frustrated staff, and • few heroes. Out of those experiences I am convinced that for software projects of any size explicit management of quality is imperative for reliable success. This is my bias. 3 Benefits The Extreme Programming approach to testing: My prediction is that in the long run Extreme Programming will enjoy more respect as a vehicle for the widespread introduction of testing worth its name, than for anything else. I have substantial doubts about how Extreme Programming addresses testing in detail as described for example in [Crispin01Testing]. One concern is that 100% test automation in most cases is not feasible and frequent releases will therefore add manual test effort. However, there is no denial of the fact that it brought testing basics to the masses. The word was written down in the testing bibles ([Beizer90STT], [Myers79AST]) decades ago, but Extreme Programming was the gospel that spread it. Would you have succeeded in convincing anybody to put 30 or 40 % of the project resources into testing, before the arrival of Extreme Programming? The visualization aspects: Besides the testing benefit, I see remarkable benefits in trying to visualize the project to all stakeholders involved. The first measure trying to achieve this is the system metaphor. Despite the fact that I consider it as naïve to assume that you can replace the system architecture by a system metaphor for anything else but trivial systems, as suggested in [Beck00XP], the idea to express the system visually is good and something I have been proposing for a long time. Despite the fact that I am not very ecstatic about the 3 x 5 cards to write down stories, I feel very positive about the visualization aspect of the project whiteboard. Transferred to the corporate intranet, these ideas are very useful. The people orientation: Extreme Programming sees itself as a “humanistic discipline of software development”. Project problems are mainly people problems, as Gerald M. Weinberg once pointed out: “No matter what the problem is, it's always a people problem”. However, it is highly doubtful to solve people problems with 2002 AVOCA GmbH Page 4 of 14 Extreme Programming Considered Harmful for Reliable Software Development AVOCA